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

Bitcoin Core has introduced a new security measure to prevent the signing of transactions that might fail to lock funds to the specific payment destination confirmed by a user.

Integrated into the master development branch of Bitcoin Core on September 25, this update addresses a specific vulnerability within partially signed Bitcoin transactions (PSBTs). This flaw could allow the generation of a valid signature while leaving the intended output unprotected.

The adjustment was spotlighted by Bitcoin Optech on October 2. While the vulnerability does not compromise a user’s private key, it presents another danger: a signature can stay valid even if the recipient of the transaction is altered under precise circumstances.

The vulnerability centers on SIGHASH_SINGLE, a signing configuration built to tie a transaction input to the output residing at the matching index. Should the transaction lack an output at that specific location, the safeguard fails differently based on the category of Bitcoin being utilized.

Regarding legacy inputs, the absence of an output can generate a signature based on a hardcoded hash value. According to Bitcoin Core developers, this signature can potentially be applied again to other unspent outputs managed by the identical key when matching structural parameters exist.

Conversely, SegWit v0 transactions maintain superior safeguards because the signature continues to bind to the exact coin being spent alongside its value. Nevertheless, the destination output can still remain unbound.

This introduces an authorization challenge for hardware signers and software wallets, as applications could display one payment destination to the user while generating a signature that lacks cryptographic proof that the approved recipient remains unaltered.

Bitcoin Core blocks the risky signing request

While Bitcoin Core’s raw-transaction signing interface previously blocked this edge case, its PSBT workflow—specifically walletprocesspsbt—was still capable of signing it.

The updated code integrates the validation directly into the shared signature-generation framework of Bitcoin Core. This blocks vulnerable legacy and SegWit v0 inputs from receiving a signature, though it permits other valid inputs within the same PSBT to be processed successfully.

PSBTs are frequently utilized for managing transactions across software wallets, offline signers, and hardware units. They enable transaction creators to transmit data to an external signing device without granting that tool access to private keys.

Consequently, this patch strengthens a vital boundary that wallet developers must uphold independently of key security: a valid cryptographic signature must commit strictly to the transaction parameters authorized by the user.

Bitcoin Improvement Proposal 174, which outlines the framework for PSBTs, instructs signers to decline unapproved signing options and advises utilizing SIGHASH_ALL when no alternative is defined. The recent update from Bitcoin Core actively blocks this missing-output setup from ever reaching the signing phase.

End users do not yet have access to an official production build that includes this defense. Although the modification was integrated into the development branch on September 25, the official release catalog of the project had not specified a patched version or verified a backport as of October 4.

As a result, hardware-signing integrations and wallet developers face an urgent choice: they should evaluate how their systems process SIGHASH_SINGLE requests independently, rather than relying on a forthcoming Bitcoin Core release to implement downstream protections.

?Frequently Asked Questions

01What is a partially signed Bitcoin transaction (PSBT)?

A PSBT is a standardized format that allows multiple parties or separate devices (like hardware wallets and software coordinators) to collaboratively build and sign a Bitcoin transaction without exposing private keys.

02Does this vulnerability expose private keys?

No, the vulnerability does not put user private keys at risk. Instead, it creates an authorization risk where a signature can remain valid even if the transaction recipient is changed under specific conditions.

03What is SIGHASH_SINGLE?

SIGHASH_SINGLE is a signing mode intended to commit a transaction input to the output at the corresponding position. If the output does not exist at that position, security gaps can occur depending on the type of Bitcoin input.