Bitcoin Core Blocks a PSBT Signing Gap That Could Move Funds
By CoinBatmi Newsroom · · 3 min read
Bitcoin Core merged a fix for a PSBT signing flaw that could allow signature reuse if outputs are missing, impacting wallet security rather than the blockchain.
Bitcoin Core has merged a fix for a narrow signing flaw that could have let a valid Bitcoin signature survive after the intended recipient was changed. No private key needs to be stolen for that to matter. The change landed in Core's master development branch on Sept.
25, 2026, as pull request #35984, and Bitcoin Optech highlighted it in its Oct. 2 newsletter. The issue lives inside a partially signed Bitcoin transaction format called a PSBT.
PSBTs let a transaction builder, a signing device, and a broadcaster pass the same unsigned deal between them without handing anyone the private keys. That structure is normal. The gap was in one signing option inside it.
The missing-output signing mode
Bitcoin transactions let a signer choose how much of the deal the signature commits to. The mode at the center of this is SIGHASH_SINGLE. It is designed to lock an input to the output sitting in the same position in the transaction.
So the second input should sign against the second output. That correspondence breaks when the output at that position does not exist. If a transaction skips that output, the protection degrades differently depending on how the Bitcoin being spent was created.
For legacy inputs, Core's description of the merged change says the signature can be produced over a fixed hash value. That kind of signature may be reusable against other unspent outputs controlled by the same key, as long as the same structural conditions are present.
SegWit v0 transactions, a newer transaction format adopted to cut fees and fix malleability, fare somewhat better. The signature still commits to the specific coin being spent and its amount. But the destination output can remain unbound.
The signer proves ownership of the coins. It does not prove the payment goes where the user was shown. That is the authorization problem wallet makers care about.
Software could present one payment on screen, then produce a signature that does not guarantee that approved recipient is unchanged. The cryptographic check, the math that should make the user's approval binding, stays silent on the destination.
What the fix actually changes
Bitcoin Core had already refused this edge case through its raw-transaction signing interface, the low-level path developers use directly. Its PSBT path, including the `walletprocesspsbt` command used by wallet software, could still sign it. The new code moves the check into Core's shared signature-creation logic.
An affected legacy or SegWit v0 input now fails to sign, while other valid inputs in the same PSBT can still proceed. The design follows the spirit of the PSBT standard.
Bitcoin Improvement Proposal 174, which defines the format, already tells signers to reject unacceptable signing modes and recommends SIGHASH_ALL, the strict option that commits to every input and output, when no alternative is specified. The Core change enforces that expectation earlier, before a malformed request can produce a signature at all.
There is nothing to patch on the blockchain itself. No funds are known to have been moved through this gap. The exposure was in wallet and signing-device logic, not in the ledger.
So the immediate burden falls on Bitcoin integrators, the teams that build wallets, hardware signers, and multisig setups, not on the network's consensus rules.
The gap between dev branch and your wallet
As of Oct. 4, 2026, Bitcoin Core's published release listings had not identified a fixed version or a confirmed backport. The safeguard exists on the development branch.
A retail user opening a wallet app today will not see any notice that their software is protected, because most mainstream wallets do not run Core's master branch. That leaves a review window for wallet providers. Hardware-signing companies and watch-only coordinators need to check how they handle SIGHASH_SINGLE requests where the matching output is absent.
Any software that signs whatever request it receives, rather than checking the signing mode against BIP 174, falls into the exposure window. Bitcoin Optech's Oct. 2 write-up is the clearest public pointer for integrators.
The concrete milestones to watch from here are a named Core release containing the fix, and statements from major wallet and hardware vendors about their SIGHASH_SINGLE handling.
Research and market information only — not financial advice.