Bitcoin Core Blocks a Signing Mode That Let Payments Be Redirected

Bitcoin Core has closed a gap that let a signed payment be pointed somewhere else. A patch merged on 25 September stops the software producing a signature when an input asks for SIGHASH_SINGLE, a mode that binds one input to the output sitting at the same position, and no output sits there. On legacy and SegWit v0 inputs the signature then survives a change of recipient. No private key is exposed by any of this. The accounts read here do not agree on whether a released build carries the change.

What the signing mode was skipping

A partially signed bitcoin transaction, or PSBT, is the file wallets pass around when more than one party has to sign, which is most multisig and hardware-wallet work. Each input carries a flag saying which parts of the transaction its signature commits to. SIGHASH_SINGLE commits to one output, the one at the same index as the input. Ask for it when that index is empty and there is nothing to commit to. Bitcoin Core's raw-transaction path had rejected that case since a change numbered 1689; the PSBT path never got the same guard, and signed anyway.

What came out differed by input type. On legacy inputs the software signed a fixed digest, the constant value one, so the signature can be valid against other unspent outputs held by the same key when the same structural conditions hold. On SegWit v0 the input commitments survive but the destination stays unbound. Neither case is a break in the cryptography. Both break what the owner approved, because a wallet can show one recipient while the signature guarantees nothing about it.

A footgun, in the pull request's words

The pull request carrying the fix, numbered 35984, is blunt about the consequence.

"The signature stays valid even when outputs are swapped, which is a footgun that lets funds be redirected without the owner's consent," its description said.

The fix moves the check into the shared routine that creates signatures, so the raw path and the PSBT path both skip the offending input while signing every other input in the same file. It closes an issue numbered 35977. Bitcoin Optech's newsletter of 2 October described the change and named that pull request, the only account read here to give a number at all. CryptoSlate, which published on Saturday evening, and a write-up carried by commstrader some fifty minutes later both date the merge to 25 September.

In master, and nobody says in which build

Where the accounts come apart is what a user should do now. CryptoSlate, the commstrader piece and a KuCoin flash all say no production release carries the safeguard, and put the work on wallet developers reviewing their own SIGHASH_SINGLE handling. A fourth write-up, on SpendNode, tells people running custom signing tooling to update to patched Core-derived software, which only makes sense if such a build exists. The two positions do not reconcile. No account read here names a version number.

Version 32.0 is the release in the queue. Its first candidate was tagged on 14 September with a release set for 10 October, so the merge landed eleven days after the candidate was cut. Whether it was pulled back into that candidate is not stated anywhere read here.

What the exposure actually requires

The conditions are narrow. Someone other than the owner has to supply or alter the transaction, and the matching index has to be empty. The request also has to use a sighash mode ordinary single-signer wallets do not reach for. SpendNode calls it a construction problem rather than a consensus failure, and both it and CryptoSlate say no keys are at risk. The disclosure credit is thin. The issue page points to a red-team report, and no outlet read here names a reporter.

Nothing read here reports a theft using this, or says how long the PSBT path behaved this way. Ledger patched an Ethereum signing flaw and then argued publicly over the disclosure in August, and the lesson the Core change points at is the same older one. A valid signature is not a promise about where the money goes. Every wallet built on Core's signing code now has to decide whether to add the guard itself.