Bitcoin Core contributors have merged a wallet-signing fix designed to prevent unsafe SIGHASH_SINGLE signatures from being generated through Partially Signed Bitcoin Transaction workflows. According to Bitcoin Core pull request #35984, merged on September 25, the affected signing path could produce a signature that was not properly bound to a corresponding transaction output, creating circumstances in which funds could be redirected without compromising the owner’s private key.
The issue affected legacy and SegWit v0 signing when a PSBT explicitly requested SIGHASH_SINGLE for an input whose matching output index did not exist. Bitcoin Optech’s October 2 technical summary confirmed that Bitcoin Core now leaves those inputs unsigned while continuing to process other valid inputs in the PSBT. The change closes a discrepancy between PSBT signing and raw transaction signing, where Bitcoin Core had already refused the problematic legacy case for years.
SIGHASH_SINGLE Can Leave an Output Uncommitted
SIGHASH_SINGLE normally lets a signer commit to the output occupying the same index as the input being signed. For example, input zero commits to output zero, while other outputs can remain outside that signature’s authorization. The security problem emerges when the corresponding output does not exist, because the intended input-to-output relationship breaks down.
For legacy transactions, Bitcoin’s longstanding SIGHASH_SINGLE quirk produces a constant signature hash of 1 when the corresponding output is missing. That means the resulting signature can become independent of the intended transaction and potentially reusable with other UTXOs controlled by the same key under the same malformed condition. SegWit v0 behaves differently, zeroing hashOutputs, but similarly fails to commit the signature to a specific output. In both cases, Bitcoin Core could previously sign a PSBT even though the signature did not provide the output commitment a user would normally expect from SIGHASH_SINGLE.
That does not mean an attacker can remotely spend arbitrary Bitcoin or derive private keys. An exploitable workflow would need the wallet to receive and sign a specially structured PSBT using the relevant sighash setting and missing output configuration. The flaw therefore sits in transaction authorization semantics, not in Bitcoin’s elliptic-curve cryptography, consensus security or private-key generation. That distinction also separates it from longer-term cryptographic issues such as the proposed migration of quantum-vulnerable Bitcoin UTXOs under BIP-361.
Fix Moves the Safety Check Into Shared Signing Logic
Bitcoin Core’s raw transaction signing path already skipped unsafe SIGHASH_SINGLE cases, but SignPSBTInput() did not apply the same protection. Pull request #35984 moves the check into shared signature-creation logic so current and future signing paths refuse to create the detached signature. A malformed PSBT can still contain the problematic structure, but Bitcoin Core will no longer supply a signature for the affected legacy or SegWit v0 input by default.
The fix is particularly relevant to workflows where PSBTs coordinate signing between hardware wallets, offline systems, multisignature participants or external services. In those environments, one party can construct a transaction while another signs only the portions it is authorized to approve. PSBT security therefore depends not only on keeping private keys secret but also on ensuring the signature commits to the transaction elements the signer believes it is authorizing.
The issue was also independently identified and responsibly disclosed by the Bitcoin Red Team, according to the Bitcoin Core issue tracker. No public material associated with the fix identifies confirmed theft caused by the bug. The change is preventative hardening against an unsafe signing state rather than a response to a disclosed Bitcoin network exploit.
The timing also matters operationally. Pull request #35984 was merged after the Bitcoin Core 32.x branch had already split from master, and as of October 5 the stable release containing the change has not been identified publicly. The merge improves Bitcoin Core’s development code, but software merged into master should not be described as protection already deployed across production Bitcoin Core wallets. That distinction is important across Bitcoin development, where proposed security changes, including broader work on future signature and custody risks, can move through review long before they become broadly deployed software.
For developers and services relying on PSBT signing, the fix closes a narrow but consequential authorization edge case. Its significance is not that Bitcoin’s signing system was broadly compromised, but that Bitcoin Core will stop creating signatures whose output commitments could be weaker than the signer intended.
Jack Reynolds is SatoshiPick’s infrastructure mind. Based in Denmark, he follows Bitcoin, Ethereum, Layer 1 networks, stablecoins and DeFi with a practical question always in the background: does this actually make crypto work better?
His articles focus on the systems beneath the headlines: settlement rails, protocol upgrades, stablecoin usage, DeFi coordination and the regulatory limits around them. Jack avoids turning technical coverage into a maze. He explains what is live, what is still experimental and why the difference matters.