Skip to content

Conversation

achow101
Copy link
Member

It can be useful to sign an input with walletprocesspsbt but not finalize that input if it is complete. This PR adds another option to walletprocesspsbt to be able to do that. We will still finalize by default.

This does not materially change the PSBT workflow since finalizepsbt needs to be called in order to extract the tx for broadcast.

@fanquake fanquake added the PSBT label Jul 21, 2021
Copy link
Member

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 81a8c35

Here is a small test exercising the new logic: darosior@cef8042

@DrahtBot
Copy link
Contributor

DrahtBot commented Jul 21, 2021

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #23602 (wallet: Split stuff from rpcwallet by MarcoFalke)
  • #23578 (Add external signer taproot support by Sjors)
  • #22558 (psbt: Taproot fields for PSBT by achow101)
  • #22514 (psbt: Actually use SIGHASH_DEFAULT for PSBT signing by achow101)
  • #21283 (Implement BIP 370 PSBTv2 by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Copy link
Contributor

@theStack theStack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

@laanwj
Copy link
Member

laanwj commented Jul 28, 2021

I'm not entirely sure whether it's better to use an options object here instead of the conventional interface with named parameters? The latter is easier to use from bitcoin-cli at least (can just use -named arg=value instead of having to wrap everything into JSON manually).

@achow101
Copy link
Member Author

I'm not entirely sure whether it's better to use an options object here instead of the conventional interface with named parameters? The latter is easier to use from bitcoin-cli at least (can just use -named arg=value instead of having to wrap everything into JSON manually).

I wonder if there is some syntactic sugar thing we can add that allows us to not have to write JSON manually.

@ryanofsky
Copy link
Contributor

I wonder if there is some syntactic sugar thing we can add that allows us to not have to write JSON manually.

If by syntactic sugar you mean a client-only change, then bitcoin-cli could accept a lighter weight YAML-like syntax and turn it into JSON. But this seems it would be a headache to maintain and a new thing users would have to learn to take advantage of.

I think a better approach, given that we already have a syntax for positional arguments, and we already have a syntax for named arguments, is to just allow these existing syntaxes to be used together. #19762 is a client+server change which does this. And it benefits not just bitcoin-cli but also other RPC clients like the python client so you can call rpc.methodname(arg1, arg2, option=value) instead of rpc.methodname(arg1, arg2, {"option": value})

A third approach which Luke at one point liked and perhaps still likes is a server-only change which translates named parameters into options values: #11441 (IIRC similar behavior was also part of #11660).

@achow101
Copy link
Member Author

I've dropped the change to use the options object since it is orthogonal to the purpose of this PR. It seems like that will need more discussion too. I've opened issue #22575 for the discussion of what to do about RPCs with lots of positional arguments.

Copy link
Member

@darosior darosior left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-ACK 7f9310d

Copy link
Member

@luke-jr luke-jr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NACK with positional bool parameter. We shouldn't make the API worse than it already is.

We don't always want to finalize after signing, so make it possible to
do that.
Copy link
Contributor

@meshcollider meshcollider left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK a99ed89

signed_tx = self.nodes[0].walletprocesspsbt(psbtx)['psbt']
signed_tx = self.nodes[0].walletprocesspsbt(psbt=psbtx, finalize=False)['psbt']
finalized_tx = self.nodes[0].walletprocesspsbt(psbt=psbtx, finalize=True)['psbt']
assert signed_tx != finalized_tx
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could also assert ['complete'] is not true before finalizing but is true afterwards

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case the result documentation for complete should also be clarified: "If the transaction has a complete set of signatures and its inputs are finalized"

luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Oct 10, 2021
We don't always want to finalize after signing, so make it possible to
do that.

Github-Pull: bitcoin#22513
Rebased-From: a99ed89
Copy link
Member

@Sjors Sjors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK a99ed89

signed_tx = self.nodes[0].walletprocesspsbt(psbtx)['psbt']
signed_tx = self.nodes[0].walletprocesspsbt(psbt=psbtx, finalize=False)['psbt']
finalized_tx = self.nodes[0].walletprocesspsbt(psbt=psbtx, finalize=True)['psbt']
assert signed_tx != finalized_tx
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case the result documentation for complete should also be clarified: "If the transaction has a complete set of signatures and its inputs are finalized"

@laanwj laanwj merged commit 383d350 into bitcoin:master Nov 29, 2021
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Nov 30, 2021
…alizing

a99ed89 psbt: sign without finalizing (Andrew Chow)

Pull request description:

  It can be useful to sign an input with `walletprocesspsbt` but not finalize that input if it is complete. This PR adds another option to `walletprocesspsbt` to be able to do that. We will still finalize by default.

  This does not materially change the PSBT workflow since `finalizepsbt` needs to be called in order to extract the tx for broadcast.

ACKs for top commit:
  meshcollider:
    utACK a99ed89
  Sjors:
    utACK a99ed89

Tree-SHA512: c88e5d3222109c5f4e763b1b9d97ce4655f68f2985a4509caab2d4e7f5bac5047328fd69696e82a330f5c5a333e0312568ae293515689b77a4747ca2f17caca6
RandyMcMillan pushed a commit to RandyMcMillan/mempool-tab that referenced this pull request Dec 23, 2021
…hout finalizing

46e07e2 psbt: sign without finalizing (Andrew Chow)

Pull request description:

  It can be useful to sign an input with `walletprocesspsbt` but not finalize that input if it is complete. This PR adds another option to `walletprocesspsbt` to be able to do that. We will still finalize by default.

  This does not materially change the PSBT workflow since `finalizepsbt` needs to be called in order to extract the tx for broadcast.

ACKs for top commit:
  meshcollider:
    utACK 46e07e2
  Sjors:
    utACK 46e07e2

Tree-SHA512: c88e5d3222109c5f4e763b1b9d97ce4655f68f2985a4509caab2d4e7f5bac5047328fd69696e82a330f5c5a333e0312568ae293515689b77a4747ca2f17caca6
@bitcoin bitcoin locked and limited conversation to collaborators Nov 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants