walletprocesspsbt says that the sighashtype argument will only be used "if not specified by the PSBT" and CWallet::FillPSBT in wallet/wallet.h says the same thing. This changes FillPSBT to actually behave that way, and as a result removes the SIGHASH_MISMATCH error code.
wallet: Don't override sighash specified in PSBT #24563
pull ajtowns wants to merge 2 commits into bitcoin:master from ajtowns:202203-fillpsbt changing 5 files +4 −14-
ajtowns commented at 3:29 PM on March 14, 2022: member
-
wallet: do not override sighash specified in psbt 371bbbcab7
- fanquake added the label Wallet on Mar 14, 2022
- fanquake requested review from achow101 on Mar 14, 2022
- ajtowns added the label PSBT on Mar 14, 2022
-
refactor: drop now unused SIGHASH_MISMATCH error e8464d41f8
- ajtowns force-pushed on Mar 16, 2022
-
ajtowns commented at 8:56 PM on March 16, 2022: member
fixed typo in commit message
-
achow101 commented at 9:39 PM on March 16, 2022: member
The original intent is to always use the sighash type given in the RPC rather than the PSBT. If the PSBT provides a sighash type, then it needs to match the sighash given in the argument.
-
ajtowns commented at 12:30 AM on March 17, 2022: member
Hmm, the psbt is supposed to "[contain] the information necessary for a signer to produce signatures for the transaction"; seems weird that you'd have to specify the sighash type via rpc, and the value in the psbt is only usable for error checking. (And I think the external signer stuff doesn't receive the rpc arg, so can only use the psbt value?) I also think this approach will make it impossible to sign a psbt that specifies an ALL signature on input 1 and a SINGLE|ANYONECANPAY signature on input 2, if the wallet happens to know both keys?
Anyway, sounds like it's not a no-brainer fix, so will close this and leave to others to worry about.
- ajtowns closed this on Mar 17, 2022
- DrahtBot locked this on Mar 17, 2023
