David Vu's Blockchain.info Wallet: Trapped With 2 BTC, Secondary Password Forgotten
IndeterminateCustodial platform became inaccessible — whether funds were recovered is not documented.
David Vu discovered a critical access failure in June 2017 when he attempted to withdraw Bitcoin from his Blockchain.info wallet. He retained access to his primary account password and could log in to view his balance of approximately 2 BTC, but the platform's required secondary password—designed to authorize transactions—had been forgotten. Compounding the problem, Vu had lost the physical backup of his 12-word recovery phrase, eliminating the standard recovery path.
Vu attempted to brute-force the secondary password using Hashcat, which failed. He then contacted Blockchain.info support and received an offer to assist in exchange for 20% of his wallet balance, a significant extraction fee. After agreeing to this arrangement, support delayed work for over a month, repeatedly claiming to be busy.
Vu had partially recovered the secondary password from memory ('davidtra....'), but several characters at the end remained unknown. Forum experts noted that Blockchain.info's architecture—concentrating transaction authorization in a secondary password with no independent reset mechanism—represented a significant custody design flaw.
The platform lacked the ability to verify account ownership through alternative means or to remove the secondary password requirement after authentication. Suggestions from experienced users included attempting to narrow down and brute-force the remaining unknown characters, requesting support to bypass the secondary password without the extraction fee, or exporting private keys if the wallet supported legacy non-HD addresses. The case highlighted the risks of depending on a single hosted platform with opaque security procedures, no documented password recovery mechanism, and support staff willing to leverage user desperation.
| Stress condition | Vendor lockout |
| Custody system | Exchange custody |
| Outcome | Indeterminate |
| Documentation | Partial |
| Year observed | 2017 |
| Country | unknown |
Why custodial Bitcoin fails differently than self-custody
Exchange custody transfers the custody problem from the holder to the institution. The holder no longer needs to manage seed phrases, maintain hardware, or understand cryptographic concepts. They need only to maintain their account. This simplicity has a cost: the holder no longer controls the private keys. Access depends entirely on the continued operational, financial, and regulatory health of the exchange.
Cases in this archive show that exchange failures cluster around specific event types: bankruptcy and insolvency, regulatory seizure, geographic sanctions, and account-level access failures (lost 2FA, forgotten email credentials). Each event type has a different recovery path and a different timeline. Bankruptcy proceedings typically take 6-24 months and produce partial recovery. Regulatory seizure timelines depend on legal process. Account access failures may be resolvable through platform support or may not.
The distinguishing feature of vendor lockout cases is that recovery — when it occurs — happens through processes the holder did not design and cannot control. They become claimants in a process rather than holders of an asset.
The primary protection against vendor lockout is not using a vendor for custody beyond what is needed operationally. Holdings intended to be stored long-term are most exposed to institutional risk. Exchange custody is well-suited for active trading and conversion; it is poorly suited for long-term storage of significant value. Moving Bitcoin off exchange into self-custody eliminates platform dependency at the cost of taking on personal custody responsibility.