Security · Wallet synchronization

The Wallet Reported Success Without Finishing Its Checks

Synchronization complete looks convincing. A user expects the wallet to have obtained the information it needs about their transactions. Yet software can sometimes finish a procedure without an error while leaving part of the work undone.

EDITORIAL OVERVIEW · Prepared by the project editors from the sources listed below.

The connection error that was not reported

Two October fixes in Bitcoin Development Kit, a collection of libraries for building wallets, demonstrated different ways this could happen.

In one Electrum synchronization code path, the library discarded errors while fetching transactions. A dropped connection or a timeout could end with a success result even though information about the requested transaction output was missing.

Consequently, an output that had already been spent could remain classified as unspent in the wallet's local state. The fix was merged on October 18: transport errors should no longer disappear silently.

It is important to distinguish a wallet's records from the state of the network. An incorrect display neither creates new bitcoin nor restores coins that have already been spent. It is the software's view of events that is wrong.

The check that made no requests

In the second case, the cause was a request-count parameter set to zero. Under certain settings, the Electrum and Esplora components could skip requests to the server and return an apparently successful empty result.

The fix was merged on October 19: these values are now treated as one rather than silently preventing requests from being made.

These reports concern specific libraries and code paths, not all Bitcoin wallets. They do not establish that every incorrect balance is caused by these bugs.

The distinction is clear even without programming knowledge: we did not obtain information about a transaction and the transaction does not exist are different statements. The repaired software stops treating the first as the second.

Sources and verification

  1. BDK #2325: transport error handling ↗
  2. BDK #2360: synchronization parameters ↗

An article about specific libraries and synchronization paths. This is not a change to Bitcoin's rules or a claim that all wallets are vulnerable.

Unless stated otherwise, the text, conclusions, structure and editorial arrangement were created by the project editors. Facts, quotations and source materials remain attributable to their authors and rights holders.

← Back to the rubric