Bitcoin Core SIGHASH_SINGLE Fix: Unbound PSBT Signatures Explained

Bitcoin Core has merged a safeguard that stops its wallet from signing a SIGHASH_SINGLE input when the transaction has no output at the same index. The change, pull request #35984, targets partially signed Bitcoin transactions (PSBTs), where a valid signature could leave the intended destination unprotected. The Bitcoin Core development log records the merge into master on 25 September 2026. The flaw does not expose private keys, but it shows why a signer should check every output before signing instead of assuming a valid signature protects the payment.

What SIGHASH_SINGLE commits to

Every Bitcoin signature includes a sighash flag that defines which parts of a transaction it covers. With SIGHASH_SINGLE, the signature commits to the output at the same index as the input being signed. BIP-143, which defines signature hashing for SegWit v0 inputs, sets hashOutputs to a 32-byte value of zeroes when no matching output exists. The signature therefore commits to no output at all.

The pull request states the consequence directly: such a signature stays valid even when outputs are swapped, which lets funds be redirected without the owner's consent. According to the same description, legacy inputs use a fixed sighash value of 1 in this situation.

Where the gap was

PSBTs, defined in BIP-174 (status: Deployed), let one party build a transaction and other parties add signatures. The pull request notes that SignTransaction() already skipped inputs in this state, but SignPSBTInput() did not. As a result, the walletprocesspsbt path could sign them. The merged change moves the check into CreateSig, so both signing paths, and any future one, skip producing the signature.

What changed and what remains unverified

Verified in primary sources: the commit "sign: skip signing SIGHASH_SINGLE inputs with no corresponding output" belongs to PR #35984, and the development log records its merge on 25 September 2026.
Secondary reporting: a CryptoSlate report, republished by CryptoRank on 4 October 2026, says the issue does not expose a user's private key. We did not independently verify that characterisation beyond the PR's description.
Not verified: which tagged Bitcoin Core release ships the change. The CryptoRank report says the merged repair had no confirmed fixed-release destination when it was written, and our sources do not establish a release date.
No evidence in the sources that the flaw was exploited.

What wallet builders and users should check

SignorCrypto's reading is that this fix covers a narrow case, while the lesson is broader: a signature is only as safe as the policy that produced it. Before signing a PSBT, signers should:

compare every output with the payment the user actually approved;
treat unusual sighash flags as a reason to review the transaction, not as a default;
confirm which software version their wallet runs once release notes identify it.

Frequently asked questions

Does this issue let attackers steal private keys?

No. The PR and the secondary report describe a way to redirect outputs without exposing keys.

Does the fix affect every Bitcoin wallet?

The sources describe only the Bitcoin Core signing path. We did not verify how other wallets or signers handle the same case.

Sources

If your team is building wallet, custody or signing infrastructure and needs a technical review of transaction-signing flows, contact SignorCrypto to discuss the work.