Bitcoin Core has added a safeguard aimed at preventing certain partially signed Bitcoin transactions from being approved without cryptographically tying the signature to the recipient chosen by the user.
The change addresses a narrow signing risk rather than a private-key theft. Under specific transaction conditions, a signature could remain valid after a payment’s destination was changed, even though the key used to authorize the transaction had not been exposed. The update was merged into Bitcoin Core’s master development branch on Sept. 25, according to reporting highlighted by CryptoSlate and Bitcoin Optech.
The issue concerns PSBTs, or partially signed Bitcoin transactions. PSBTs are used when several pieces of software or devices take part in building and authorizing a transaction. For example, a software wallet may assemble a transaction, then send it to a hardware wallet or offline signer for approval. The design allows the signing device to authorize a transaction without handing over its private keys.
That separation protects key material, but it does not by itself guarantee that the signature covers every transaction detail the user saw and approved. The Bitcoin Core change focuses on closing that gap.
Why the signing mode matters
The weakness involves SIGHASH_SINGLE, a Bitcoin signature mode intended to link an input to the output in the same position within a transaction. If there is no output in that position, the protection does not operate as intended, with the consequences differing according to the type of Bitcoin input being spent.
For legacy inputs, the missing-output situation can result in a signature over a fixed hash value. Bitcoin Core developers said that, under the same structural conditions, such a signature could be reused against other unspent outputs controlled by the same key.
SegWit v0 inputs retain stronger protection in this situation because the signature continues to commit to the specific coin being spent and its amount. However, the destination output can still remain outside the signature’s commitment. In practical terms, a wallet or signing device might display one recipient to the user while producing a signature that does not guarantee the approved recipient will remain unchanged.
This is an authorization problem, not a claim that private keys can be recovered or stolen. A cryptographic signature can be mathematically valid while failing to bind the payment to the destination that the user intended to authorize.
Bitcoin Core moves the check into shared signing logic
Bitcoin Core already rejected the relevant edge case through its raw-transaction signing interface. The PSBT route, including the walletprocesspsbt function, could nevertheless continue to sign transactions with the problematic configuration.
The newly merged code places the check in Bitcoin Core’s shared signature-creation logic. It blocks affected legacy and SegWit v0 inputs from being signed, while permitting other valid inputs in the same PSBT to continue. That approach targets the risky request at the point where a signature is created rather than relying only on a particular transaction interface to reject it.
The PSBT standard, defined by Bitcoin Improvement Proposal 174, already instructs signers to reject unacceptable signing modes and recommends SIGHASH_ALL when no alternative is specified. The new Bitcoin Core safeguard specifically prevents the missing-output configuration described in the issue from reaching the signing stage.
The broader significance is that wallet developers must treat transaction authorization and key security as separate responsibilities. Keeping a private key offline or inside a hardware device can protect the key, but the signing software must also ensure that the signature commits to the payment information the user approved.
No confirmed production release yet
The safeguard is not yet confirmed in a published Bitcoin Core production release. As of Oct. 4, the change remained in the project’s development branch, and the published release listings had not identified a fixed version or confirmed a backport containing it.
That leaves wallet companies and hardware-signing integrations with an immediate implementation question. They may need to review how their own systems handle SIGHASH_SINGLE requests rather than waiting for a future Bitcoin Core release to enforce the same check downstream.
For users, the material point is that the change concerns a narrow transaction-signing scenario. It does not indicate that Bitcoin private keys have been exposed. Instead, it reinforces the requirement that wallet software and signing devices verify not only whether a signature is valid, but also whether it is tied to the transaction details the user actually approved.
Current Bitcoin market picture
Moneyiar market data at 09:49 on Oct. 5, 2026, put Bitcoin at $85,941.068904725, up 0.75% over 24 hours and 3.91% over seven days. The same data showed FUNToken at $0.0079947991, down 0.37% in 24 hours and up 6.84% over seven days.
Request was priced at $0.0559981109, with a 24-hour gain of 0.81% and a seven-day change of 0.08%. RedStone stood at $0.1720966834, down 2.43% over 24 hours but up 7.57% over seven days. These figures are Moneyiar data recorded at the stated times.
