Bitcoin Core merged a safeguard into its master development branch on Sept. 25, blocking a narrow PSBT signing case that could leave a payment destination unprotected. The issue involves SIGHASH_SINGLE, a signing mode that normally links an input to the output in the same position. When that output is absent, a signature can remain valid without binding the intended recipient.
Why it matters
The flaw does not expose private keys. It creates an authorization risk: under specific conditions, a wallet or signing device could show one recipient while producing a signature that does not ensure the transaction still pays that recipient. Bitcoin Core developers said affected legacy signatures may be reusable against other unspent outputs controlled by the same key when the same structural conditions apply. SegWit v0 retains a commitment to the specific coin and its amount, but the destination output can still be left unbound.
PSBTs let software wallets, hardware devices and offline signers coordinate transactions without handing private keys to the transaction builder. That makes the signing boundary important: a valid signature should commit to the details the user approved. BIP 174 already advises signers to reject unacceptable signing modes and recommends SIGHASH_ALL when no alternative is specified.
Market impact
Bitcoin Core already rejected this edge case through its raw-transaction signing interface, but the PSBT path, including walletprocesspsbt, could still sign it. The merged change moves the check into shared signature-creation logic, blocking affected legacy and SegWit v0 inputs while allowing other valid inputs in the same PSBT to proceed.
The safeguard was merged to the development branch, but no production release containing it had been confirmed as of Oct. 4. Wallet providers and hardware-signing integrations therefore need to review their own handling of SIGHASH_SINGLE requests while users wait for a release or backport.
Frequently asked questions
-
What risk did the Bitcoin Core safeguard address?
A PSBT could be signed even when the signature did not bind the payment destination the user approved. The issue did not expose private keys.
-
How does SIGHASH_SINGLE relate to the missing-output case?
SIGHASH_SINGLE is designed to link an input to the output in the same position. If that output is absent, the signature may not protect the intended destination.
-
Did the issue affect legacy and SegWit v0 inputs in the same way?
No. Developers said affected legacy signatures may be reusable against other unspent outputs under matching conditions. SegWit v0 still commits to the coin and amount, although the destination can remain unbound.
-
Why does the PSBT signing path matter to wallet users?
PSBTs coordinate transactions between software wallets, hardware devices and offline signers. A signer needs to ensure the transaction details match what the user approved.
-
Was the safeguard available in a Bitcoin Core production release?
The change was merged into Bitcoin Core’s development branch on Sept. 25. No production release containing it or confirmed backport had been identified as of Oct. 4.
CryptoSlate