Bitcoin Core has introduced a critical security safeguard designed to prevent the signing of transactions that fail to bind user funds securely to an approved payment destination. Merged into the master development branch of Bitcoin Core on September 25, the update addresses a specific and subtle flaw within Partially Signed Bitcoin Transactions, commonly referred to as PSBTs. This vulnerability could theoretically allow a valid cryptographic signature to be generated without adequately protecting the intended transaction output.
The update was subsequently highlighted by Bitcoin Optech in its early October technical review. Security analysts have clarified that the flaw does not expose or compromise a user’s private keys. Instead, it presents a different kind of operational risk: under precise and narrow structural conditions, a signature can remain entirely valid even if the underlying recipient of the transaction has been altered after the user’s initial authorization.
At the heart of the weakness lies SIGHASH_SINGLE, a specific transaction signing mode designed to commit a transaction input to the corresponding output located at the exact same index position. However, if a transaction happens to contain no output at that designated position, the safety mechanisms break down in distinct ways depending on the specific type of Bitcoin being spent.
For legacy inputs, this missing-output scenario can produce a signature over a fixed hash value. According to Bitcoin Core developers, that specific signature might then be reusable against other unspent outputs controlled by the same cryptographic key if identical structural conditions are met elsewhere.
Meanwhile, SegWit v0 transactions maintain a higher level of protection because the resulting signature still commits directly to the specific coin being spent and its precise numerical amount. Even so, the final destination output can remain unbound under these flawed conditions. This creates a challenging authorization dilemma for modern software wallets and hardware signing devices. Wallet software might present one intended payment path to a user, yet simultaneously produce a cryptographic signature that fails to guarantee that the approved recipient remains immutable.
Bitcoin Core Blocks Risky Signing Requests at the Core Logic Level
Historically, Bitcoin Core possessed mechanisms to reject this particular edge case through its raw-transaction signing interface. Yet, its designated PSBT path—including functions such as walletprocesspsbt—could still inadvertently process and sign the vulnerable transaction structure.
The newly merged code shifts this critical validation check directly into Bitcoin Core’s shared signature-creation logic. By doing so, it proactively prevents affected legacy and SegWit v0 inputs from ever being signed. At the same time, it ensures that other entirely valid, unaffected inputs within the exact same PSBT are permitted to proceed smoothly without disruption.
Partially Signed Bitcoin Transactions are widely utilized across the ecosystem to facilitate complex transaction coordination between modern software wallets, dedicated hardware devices, and air-gapped offline signers. They allow transaction builders to pass necessary data to a separate signing environment without relinquishing control of the underlying private keys to that software.
Consequently, the latest fix reinforces an essential architectural boundary that wallet developers must maintain independently of key security: a valid cryptographic signature must strictly and unambiguously commit to the precise transaction details that the user has consciously authorized.
Bitcoin Improvement Proposal 174, which formally defines the standard for PSBTs, already instructs signers to reject unacceptable signing modes and actively recommends utilizing SIGHASH_ALL whenever no alternative mode is explicitly specified. The latest update to Bitcoin Core takes this a step further by systematically preventing this dangerous missing-output configuration from ever reaching the signing stage.
As of early October, general users do not yet have access to a confirmed production software release containing this new safeguard, as the code change was only recently merged into the development branch and has not yet been assigned to a stable release version or backported.
This current state of affairs places an immediate responsibility on third-party wallet providers and hardware-signing device integrations. Rather than waiting for an official production release from Bitcoin Core to enforce downstream protection, these developers are advised to independently review and tighten how their systems handle SIGHASH_SINGLE signing requests.
