Bitcoin Transfer Stalled Between Bither Wallets—Old Laptop to New, 3+ Months Unresolved
IndeterminateHardware device was lost or destroyed — whether access was recovered is not documented.
A caregiver assisted their friend (who has disability-related constraints preventing direct technical engagement) in attempting to consolidate Bitcoin holdings. The friend held Bitcoin on an older Bither wallet installed on a Dell laptop running Windows 7 Professional, version 1.4.5, estimated to date from around 2008.
To prepare for eventual liquidation due to complexity concerns, the friend created a newer Bither wallet on a second laptop purchased around 2018–2019. The caregiver initiated a transfer from the legacy wallet using the Send feature, entering what they believed to be the destination account identifier (likely a wallet address or QR code) from the newer wallet. The old Bither wallet displayed a white dot indicator—typically denoting a pending or processed transaction. However, the newer Bither wallet showed no corresponding transaction record.
After several months of waiting with no confirmation or arrival of funds, the caregiver posted to Bitcoin Stack Exchange seeking clarification on the missing transaction. The specific amount of Bitcoin involved was not disclosed. Key uncertainties included the exact Bither version on the newer wallet, the precise format of the identifier used (address vs. label vs.
QR code), and whether Bither v1.4.5 had known synchronization or broadcast issues. The case remained unresolved at the time of posting, with the caregiver and owner unable to locate the funds or definitively determine whether the transaction had broadcast to the network, been rejected, or been lost due to version incompatibility.
| Stress condition | Device loss |
| Custody system | Software wallet |
| Outcome | Indeterminate |
| Documentation | Partial |
| Year observed | 2008 |
| Country | United States |
What determines whether device loss is permanent
When a device fails, burns, floods, or disappears, the Bitcoin remains on the blockchain, unchanged. What changes is whether any path to authorized access still exists. A seed phrase stored separately from the device preserves that path. A seed phrase stored with the device — or never recorded at all — eliminates it permanently.
The pattern observed across cases in this archive is consistent: recovery is possible when the seed phrase survived the event that took the device. It is not possible when it did not. The type of device, its cost, its brand, its security features — none of these factors determine the outcome. The seed phrase backup does.
Most device loss cases that result in permanent loss involve one of three failure modes: the seed phrase was never recorded at setup, the seed phrase was stored physically alongside the device and lost with it, or the seed phrase was stored in a location that became inaccessible during the same event (flood, fire, relocation). All three are detectable in advance. A backup test — confirming that the seed phrase can restore the wallet on a separate device — would have revealed the gap before the loss event.
A device loss case becomes unrecoverable the moment the backup path is also broken. The preventive action is simple in concept: record the seed phrase at setup, store it independently from the device, and test that it works. Most cases in this archive involved none of these three steps.
Translate