Bitcoin transaction path passing through a signing security checkpoint while a malformed path is rejected

Bitcoin Core Closes a PSBT Signing Gap That Could Redirect a Payment

By Isaac • October 4, 2026 3:20 pm • Comments

Bitcoin Core has closed a narrow signing gap that could matter whenever a wallet, hardware device, or offline signer is asked to approve a partially signed Bitcoin transaction.

The safeguard does not respond to stolen private keys. It tackles a different problem: under a specific malformed setup, software could produce a valid signature without cryptographically locking that signature to the destination the user believed had been approved.

That distinction is important. A signature can be mathematically valid and still fail to protect the exact payment instruction shown on the screen.

Trending: Chainalysis Says AI Traced the $387 Million Bitget Hack in Under 10 Minutes

CryptoSlate reports that the change was merged into Bitcoin Core’s master development branch on September 25. It targets certain uses of SIGHASH_SINGLE, a signing mode intended to connect an input with the output in the matching position.

If that corresponding output is missing, the protection can break down. For legacy inputs, the edge case can create a signature over a fixed hash value that may be reusable against other unspent outputs controlled by the same key when the same structural conditions are present.

SegWit v0 limits part of that exposure by tying the signature to the specific coin and amount. The intended destination can still remain unbound.

For everyday users, the practical issue is authorization. A signer has to confirm more than the validity of the spending key.

The signed transaction also has to preserve the recipient and other terms the user reviewed.

BIP 174 defines the PSBT format used to move transaction information between builders and signers. That separation helps multisignature setups, hardware wallets, and offline signers keep private keys away from the machine assembling a transaction.

The signer still has to be strict about what it accepts. BIP 174 tells signers to reject unacceptable signing modes and recommends SIGHASH_ALL when no alternative is specified.

Bitcoin Core’s raw-transaction signing interface already rejected this missing-output edge case. The PSBT route, including walletprocesspsbt, could still sign it.

The new check moves the protection into shared signature-creation logic. Affected legacy and SegWit v0 inputs are refused while other valid inputs in the same PSBT can continue.

The underlying code change is available in Bitcoin Core pull request 35984, and Bitcoin Optech highlighted it in its October 2 newsletter.

As of October 4, Bitcoin Core had not identified a confirmed production release or backport containing this exact safeguard. The project’s v32.0 release candidate is already being tested, but the development-branch merge and the release-candidate announcement should not be treated as proof that the fix is in a shipping build.

That leaves wallet providers and hardware-signing teams with a clear job now: review how their own software handles SIGHASH_SINGLE requests when the matching output does not exist.

Bitcoin’s signature system has not suffered a broad break. The change instead draws a hard line between key security and transaction authorization.

A protected private key cannot save a user from a signer that approves a transaction without binding the destination shown on the screen.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.

 

Search ProCoinNews