Bitcoin Core stops signing SIGHASH_SINGLE inputs that have no matching output
Serguey Asael Shinder2 min readBitcoin Core has merged a change that refuses to sign a particular kind of input that could let funds be redirected without the owner's private key. Pull request #35984, by developer furszy, was merged into the master branch on 25 September. Bitcoin Optech highlighted it in its newsletter on 2 October.
The flaw. A signature made with SIGHASH_SINGLE commits only to the transaction output at the same index as the input being signed. If no output exists at that position, the signature commits to no output at all. For legacy inputs it is made over a fixed hash value of 1, and for SegWit v0 inputs the output commitment is zeroed. Either way, the pull request explains, the signature stays valid even when the outputs are swapped, which it calls "a footgun that lets funds be redirected without the owner's consent".
Why only one path was protected. Bitcoin Core's SignTransaction() function already skipped such inputs, but SignPSBTInput(), used when signing partially signed Bitcoin transactions, did not, so the wallet RPC walletprocesspsbt would sign them. The fix moves the check into CreateSig, the shared signature-creation code, so both paths and any future one skip producing the detached signature, while other valid inputs in the same PSBT are still signed.
A deliberate choice, not a default. The author notes that if a legitimate use for the SegWit v0 case exists, it should be re-allowed through an explicit opt-in argument rather than by default, so that it is always a deliberate choice. The change fixes issue #35977.
Who is affected. PSBTs are how software wallets, hardware devices and offline signers pass a transaction between them without sharing keys. The risk is a signer that shows the user one payment while producing a signature that does not guarantee that payment. BIP 174, which defines PSBTs, already tells signers to reject unacceptable signature-hash types. The change is on the development branch and, as of this writing, not in a published release.
What it means
The bug class is old and well documented, which is why it matters that a path was still open. Wallet and signing-device developers should check their own PSBT signing for the same case rather than wait for a Bitcoin Core release: a correct signature has to commit to the payment the user approved, independently of how safe the key is.