Bitcoin Core Fixes Signing Bug That Could Redirect Funds

Bitcoin’s PSBT bug leaves a payment output unprotected

A PSBT is a package containing an unfinished transaction and information needed to sign it. Bitcoin Core’s workflow documentation describes its use in hardware-wallet, multisignature and collaborative transactions, where constructing a payment and authorizing it can happen in different systems.

Inputs identify coins being spent. Outputs specify where value goes. A signature’s mode determines which transaction details it protects against later changes. In the mode involved here, called SIGHASH_SINGLE, each signed input normally protects the output in the corresponding position.

The failure appears when that output does not exist. Bitcoin Optech’s technical account explains that legacy signing then produces a signature over a constant hash. Such a signature may be reused for other unspent coins controlled by the same key if the corresponding-output condition remains unmet.

SegWit v0 behaves differently. Its signature specification, BIP 143, retains commitments to the coin being spent and its amount, but sets the output hash to zero in this case. That preserves some transaction protections while leaving the intended destination outside the signature’s guarantee.

This is a narrower exposure than saying every Bitcoin transaction can be redirected. It requires the relevant signing mode, input type and transaction structure. The disclosure provides no basis for treating all hardware wallets, multisignature accounts or Bitcoin addresses as vulnerable.

The distinction also separates this report from confirmed Coldcard-related theft waves. That coverage involved a different seed-generation issue and on-chain loss estimates. Those figures cannot be transferred to the Bitcoin Core signing gap.

Bitcoin Core’s safeguard skips unsafe signatures

The code changes and regression tests move the missing-output check into shared signature-creation logic. Rather than producing the unsafe signature, the updated code leaves that input unsigned. Other eligible inputs in the same PSBT can still be signed.

Raw-transaction signing already refused this configuration, while the PSBT route could still sign it through walletprocesspsbt. Bringing both paths under the shared check closes that inconsistency and reduces the chance that a future entry point omits the same safeguard.

The tests construct a transaction with two inputs and one output, then check the signing outcome across legacy, SegWit and Taproot address types. This tests the precise position mismatch behind the bug, rather than merely checking whether an ordinary payment succeeds.

Taproot has a separate rule. BIP 341 requires signature validation to fail if SIGHASH_SINGLE is used without a corresponding output. Its treatment should not be confused with legacy’s constant-hash result or SegWit v0’s unbound output.

The repair changes wallet signing behavior. The published patch does not change Bitcoin’s consensus rules or announce a network fork. Its purpose is to prevent software from issuing a dangerous authorization under rules the network already recognizes.

The PSBT standard, BIP 174, already requires signers to reject unacceptable signature modes. It recommends SIGHASH_ALL when a mode is not supplied, while permitting implementations to choose another. This reinforces the need to inspect both the selected mode and the transaction being authorized.

Keeping a key offline protects a different boundary. A signing device can keep its secret secure while approving a signature with insufficient restrictions on what happens next. That is an implementation question for the signer and its coordinating software, not a conclusion that offline custody is inherently unsafe.

The broader debate over quantum-resistant Bitcoin wallets addresses another cryptographic threat. This repair concerns present-day authorization logic, so it should not be presented as a quantum-security upgrade.

A stable Bitcoin Core release remains unverified

Bitcoin Core’s official download page listed version 31.1 at publication. The reviewed release records did not independently establish a stable version containing this September 25 change or a confirmed maintenance backport.

A merge into the master branch establishes that developers accepted the code. It does not establish that an installed wallet has it, that a distribution has packaged it, or that a hardware signer uses Bitcoin Core’s implementation. Those are separate deployment questions.

The absence of confirmed exploitation also limits the available impact assessment. Neither the initial disclosure nor the repair record provides victim addresses, transaction hashes, an affected-wallet census or a loss estimate. Searches for incident reporting and specialist analytics did not identify credible evidence tying those measures to this gap.

For wallet providers, a useful next disclosure would identify the affected signing path, the release or firmware containing protection, and how unusual signing requests are handled. Users need implementation-specific confirmation before interpreting a general headline as proof their software has been repaired.

A PSBT containing an unsigned required input cannot yet become a fully authorized payment. Refusal to sign is therefore an intended protective outcome.

That release distinction also shaped coverage of Tangem’s laboratory attack dispute, where the ability to update deployed hardware was central. Here, the open question is delivery of a software safeguard and its adoption by individual signing systems.

Alternative.me showed 70, classified as Greed, against 65 the previous day. Its Bitcoin-focused sentiment measure does not assess wallet safety or quantify this bug’s impact.

The next concrete milestones are a release note naming the fix, any verified backport, and wallet-provider statements about their own handling. Confirmed theft evidence would change the loss assessment; until then, the documented event is a preventive signing repair with an unresolved deployment timetable.