区块链从未丢失这些币。
钱包失去花费能力。
这一区别将故事从坏U盘转为钱包架构问题。早期Bitcoin未从单一可恢复种子派生所有未来密钥，备份仅是复制时密钥快照。
目录
损失之夜
细致备份、1 BTC 自付与一次重启带来的深远影响
Stone Man积累了9,000 BTC，转入运行于Debian live CD的Bitcoin客户端。该系统驻留内存，关机会清除活动钱包，他先将wallet.dat复制到U盘。
- 01
保护
钱包已备份
9,000 BTC的wallet.dat从活动系统复制到U盘。
- 02
自付
Stone Man 向自己发送约 1 BTC
在确认另一笔付款何时到账时，Stone Man 向自己发送约 1 BTC。钱包花费了全部 9,000 BTC 输出，并悄悄为剩余部分创建了新的找零密钥。
- 03
擦除
活动系统关闭
包含新找零密钥的内存钱包在备份刷新前消失。
- 04
恢复
旧备份恢复
区块链显示交易，但恢复的钱包无法花费8,999 BTC找零输出。
“我从未想过它会影响我的全部余额。”
关于 Stone Man 我们所知的情况
Stone Man 是谁？
Stone Man 的真实身份未知。他在 BitcoinTalk 的账号是 288。在论坛中，他说自己逐步购买了 9,000 BTC，使用 Debian live CD 运行比特币，并在关机前保存了 wallet.dat 的副本。
我们不知道他的真实姓名、居住地、职业，也不清楚帖子之后发生了什么。后续关于他身份的说法尚未证实。
寻找丢失的密钥
人们从 2010 年开始寻找密钥
Stone Man 请求帮助几分钟后，另一位用户主动检查旧钱包。Insti 使用 Gavin Andresen 早期的比特币工具重建了交易。成功恢复需要保存的 wallet.dat 包含找零地址的私钥。2010 年的分析表明，可能并不包含该私钥。没有这个密钥，区块链能显示币的位置，但无人能转移它们。
首次尝试恢复密钥
论坛用户追踪了两个交易输出，要求 Stone Man 列出钱包中的密钥，并找到了丢失的找零地址。他们能解释损失原因，但无法恢复密钥。
2026 年的新搜索
2026 年，一位匿名论坛用户表示他们用 GPU 测试了超过 650 万个可能的密钥，但没有匹配丢失的地址。他们说需要 Stone Man 和他旧钱包的详细信息来缩小搜索范围。
交易剖析
为何发送1 BTC转移了全部9,000 BTC
Bitcoin以完整单元花费交易输出。Stone Man的钱包使用了一个9,000 BTC输出，返还1 BTC到他选择的地址，另生成8,999 BTC找零输出。该找零非盗窃支付。
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg隐藏的失败
wallet.dat是快照，不是未来密钥的承诺
原始Bitcoin钱包存储独立生成的私钥。需要新找零地址时，可在备份后生成新密钥。恢复旧文件恢复旧密钥，但无法重建后续随机密钥。
区块链重新扫描可重新发现交易，显示8,999 BTC去向，但无法生成缺失的私钥。可见性不等于控制权。
警告先行
Stone Man不是首个因找零问题受困者
2010年7月14日，Stone Man发帖近一个月前，另一用户描述了类似但规模较小的失败。他备份了持有1.21 BTC的钱包，捐赠0.01 BTC，恢复旧文件后余额归零。
到7月21日，用户明确警告旧备份可能包含已用密钥但不含新生成找零密钥。危险在8,999 BTC事件前已公开。
比特币的变化
从散列密钥到密钥池，再到确定性钱包
回应并非一次完美修复。Bitcoin先创建未来密钥安全缓冲，后续钱包设计使整组密钥可从单一根种子恢复。
-
观察到失败
1.20 BTC 警告
用户在捐赠0.01 BTC后恢复旧钱包，丢失对新生成找零输出的访问权限。
-
设计方案
中本聪描述未来密钥队列
预生成地址让备份包含钱包尚未使用的密钥。
-
失败加剧
Stone Man丢失了8,999 BTC找零私钥
同样的架构弱点让社区无法忽视。
-
安全缓冲区已发布
Bitcoin 0.3.13.3引入密钥池
默认100个预生成密钥池为备份提供有限的未来覆盖窗口。
-
确定性标准
BIP 32定义了从一个种子生成的密钥树
钱包可从可恢复根派生未来收款和找零密钥，而非仅存储无关随机密钥。
-
默认启用HD
Bitcoin Core采用确定性密钥推导
新建HD钱包中，正确的种子备份可重建钱包派生密钥。
103849419a9c014a69c76b6f96e48b66cbc838ca
该提交更改交易创建，改为从默认100个预生成密钥池中预留找零密钥，而非交易构建时才生成。
这意味着什么
现代助记词改变了恢复方式，但未使备份可选
分层确定性钱包从一个种子派生多个密钥，正确恢复种子和推导信息时不会发生Stone Man的故障。Bitcoin Core 0.13引入HD钱包，但导入密钥、旧非HD钱包、未知推导路径、丢失密码、损坏备份和未测试恢复仍可能导致资金丢失。
了解你的备份类型
助记词、描述符导出、wallet.dat文件、硬件钱包备份和导入私钥的恢复方式不同。
测试恢复，不转移真实资金
在紧急情况迫使你猜测前，验证恢复钱包能推导预期收款和找零地址。
将导入密钥视为独立风险
原始种子或备份后导入的密钥可能需单独导出，不能总从恢复短语重建。
谨慎迁移重要旧钱包
用最新恢复材料创建钱包，验证备份，发送小额测试，再转移剩余余额。
长远教训
备份的完整性取决于其背后的密钥模型
Stone Man的损失非比特币密码学破裂，也非未知攻击者盗取钱包，而是恢复设计缺陷被普通交易暴露。网络完美保存账本，旧备份保存了错误时间点。
主要来源与验证
跟踪论坛记录、交易和代码
上述历史说法已与当时BitcoinTalk帖子、公开交易记录、原始密钥池提交、BIP 32及现行Bitcoin Core钱包文档核对。
常见问题
Stone Man真的丢失了8,999 BTC吗？
公开交易花费一个9,000 BTC输出，生成1 BTC和8,999 BTC输出。Stone Man报告恢复备份缺少8,999 BTC找零地址私钥，且该地址在本文验证时未花费任何输出。
为何Stone Man的wallet.dat备份未能恢复币？
备份创建于钱包生成新找零地址私钥之前。早期非确定性钱包无法从旧密钥或区块链重建后续随机密钥。
8,999 BTC输出是黑客攻击还是支付给攻击者？
无需攻击者解释交易。8,999 BTC是Stone Man自付1 BTC的找零输出，失败在于丢失了花费该找零的私钥。
现代助记词会出现同样的钱包备份问题吗？
正确恢复的确定性钱包可从正确种子推导预期的收款和找零密钥。若种子错误或不完整、推导设置未知、密钥单独导入、缺少密码短语或未测试备份，恢复仍可能失败。
我们知道 Stone Man 发生了什么吗？
Stone Man 在论坛求助，称仍持有旧钱包文件并回答技术问题，后来停止发帖。我们不清楚原因，也不知他是否私下继续尝试恢复密钥。