A Bitcoin wallet can know the latest chain height and still misunderstand where a payment is confirmed. Bitcoin Dev Kit’s pull request #2319, merged on October 12, addresses an Electrum synchronization bug in which a transaction mined again at its original height after a reorganization could retain an outdated confirmation anchor.
The practical question for October 18 is how wallet developers carry that correction into the applications people actually use. An upstream merge establishes that a change entered a repository branch. Determining whether a particular installed wallet includes it requires checking that product’s dependencies and release history.
The height can stay the same while the block changes
Bitcoin’s developer guide explains that competing blocks can occupy the same height. When the network settles on the valid branch with the most accumulated proof of work, blocks on the other branch become stale. A height describes a position in a chain; it cannot uniquely identify the block occupying that position. The guide therefore distinguishes height from a block’s header hash. Bitcoin developer guide
Consider a simplified example: transaction T appears in block A at height H. A reorganization replaces A with block B, and B also includes T. The transaction identifier and confirmation height can both remain unchanged, although the block providing the confirmation has changed. A wallet must reconcile that change before interpreting its stored transaction information.
BDK’s own data model reflects this requirement. Its BlockId structure contains both a height and a block hash. Those two fields express the distinction that a single progress counter cannot preserve. BDK BlockId documentation
How an optimization preserved the wrong answer
The header cache could retain the displaced block. Because the anchor cache used transaction ID and block hash, that obsolete header could trigger a cache hit and skip fresh proof validation.
The patch refreshes cached headers during chain updates. Regression tests cover synchronization immediately after a reorganization and after another 20 blocks. A one-block reorganization can trigger the documented failure. Fix and tests
Why the balance screen depends on chain identity
The affected component has a specific role. BDK’s Electrum integration returns updates from Electrum servers. Its documentation distinguishes ordinary synchronization of relevant script histories from a fuller scan used when importing or restoring a keychain whose used range is unknown. That scope matters when investigating whether an application uses the affected path. BDK Electrum documentation
BDK’s wallet API also distinguishes stored transaction anchors from a transaction’s position in the best chain: an anchor may refer to a block that is no longer in that chain. Its balance interface separates funds into categories including pending amounts. A product that displays confirmed and pending balances consequently needs its confirmation classification to agree with its current chain view. Applied to this bug, the implication is that a transaction can appear unconfirmed even after being mined in the replacement block. The exact balance-screen symptom depends on the application built around the library. BDK Wallet documentation
The chain-update interface makes the consistency requirement explicit. Updates must establish which existing blocks remain valid and which are displaced; a different hash at the same height can identify the point that must be invalidated. This is a useful review criterion for any additional application-level cache. BDK LocalChain documentation
Release diligence is part of the fix
A separate release-preparation PR, #2225, merged October 12, includes a version bump for bdk_electrum to 0.24.1. That is a concrete dependency trail for maintainers to investigate. It does not establish the version bundled in any particular wallet distributed through an app store or another channel.
For developers, the sensible acceptance test extends to the finished product: reproduce a reorganization, synchronize through the normal application workflow, and inspect transaction status and balance categories together. Repeat after a restart to check the persisted result. BDK documents that applying a wallet update stages changes and that applications should persist them afterward; persistence belongs in an integration test alongside network synchronization. Wallet update documentation
The broader lesson is straightforward: a healthy sync indicator should mean that the wallet’s transaction evidence, chain view and displayed state agree. Counting upward is only one part of keeping that promise.