AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 68 Bitcoin

verify inclusion proofs for newly confirmed transactions, leaving them unconfirmed where they cannot be proved

Public commit record

What the developer wrote

Authored by Craig Raw

60/100 · Adequate
verify inclusion proofs for newly confirmed transactions, leaving them unconfirmed where they cannot be proved
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Mentions testing or verification! No meaningful explanatory body
The short version

What changed, and why it matters

This commit adds a security feature to Sparrow Wallet that verifies Bitcoin transaction inclusion proofs supplied by Electrum servers. Before this change, the wallet trusted the server when it reported a transaction as 'confirmed' in a particular block. Now, for newly confirmed transactions, the wallet asks the server for a cryptographic Merkle proof and checks it against a verified block header. If the proof is missing, wrong, or for a different block, the transaction is demoted to 'unconfirmed' and the user is warned that the server may be faulty or dishonest. The change protects users against a malicious or compromised server falsely claiming a transaction was confirmed.

Recommended action

This is a defensive hardening commit. Users and downstream packagers should ensure they upgrade to a release containing this commit, especially when using public Electrum servers. Operators should monitor for the new 'Transaction Verification Failed/Refused' dialogs and consider switching servers if they appear. No immediate mitigation is needed beyond applying the update; the change is enabled by default.

Security signals we found

01

Adds cryptographic verification of server-reported transaction confirmations (Merkle proofs against verified headers)

02

Demotes unverifiable confirmed transactions to unconfirmed instead of accepting server claims

03

Distinguishes server 'refusal' from 'dishonest/faulty' proof failure and surfaces distinct user dialogs

04

Adds retry/backoff logic to avoid false positives from transient server errors

05

Makes verification mandatory for public Electrum servers on mainnet

06

Disables verification for user's own Bitcoin Core node (trusted anyway)

07

Handles CVE-2017-12842-style 64-byte transaction forgery by rejecting inner Merkle nodes that deserialize as transactions

08

Clears stale announced-tip header cache above reorg fork to avoid serving orphaned block metadata

09

Records block hash on stored transactions to detect same-height reorgs

Risk score

Why this scored 68/100

Our methodology →
Potential impact 22/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.