Bitcoin Core’s new fix closes gap that could redirect funds without stealing keys

The weakness involves SIGHASH_SINGLEwhich is a signing mode designed to commit an input to the output in the corresponding position. If the transaction contains no output at that position, the protection breaks down differently depending on the type of Bitcoin being spent.

For legacy inputs, the missing-output case can produce a signature over a fixed hash value. Bitcoin Core developers said that signature may then be reusable against other unspent outputs controlled by the same key when the same structural conditions are present.

SegWit v0 transactions retain stronger protections because the signature still commits to the specific coin being spent and its amount. The destination output, however, can remain unbound.

That creates an authorization problem for wallets and signing devices: software could present one payment to the user while producing a signature that does not cryptographically guarantee that the approved recipient remains unchanged.

Bitcoin Core blocks the risky signing request

Bitcoin Core already rejected the edge case through its raw-transaction signing interface. Its PSBT path, including walletprocesspsbtcould still sign it.

The new code moves the check into Bitcoin Core’s shared signature-creation logic, preventing affected legacy and SegWit v0 inputs from being signed while allowing other valid inputs in the same PSBT to proceed.

PSBTs are commonly used to coordinate transactions between software wallets, hardware devices and offline signers. They allow transaction builders to pass information to a separate signer without giving that system control of the private keys.

The fix therefore reinforces a boundary that wallet developers must enforce independently of key security: a valid cryptographic signature must commit to the transaction details the user actually authorized.

Bitcoin Improvement Proposal 174, which defines PSBTs, already tells signers to reject unacceptable signing modes and recommends SIGHASH_ALL when no alternative is specified. The Bitcoin Core change explicitly prevents this missing-output configuration from reaching the signing stage.

Users do not yet have a confirmed production release containing the safeguard. The Sept. 25 change was merged into Bitcoin Core’s development branch, while the project’s published release listings had not identified a fixed version or confirmed backport as of Oct. 4.

That leaves wallet providers and hardware-signing integrations with the more immediate decision: review their own handling of SIGHASH_SINGLE requests rather than waiting for a Bitcoin Core release to enforce the same protection downstream.