SLIP39备份恢复：凑够份数，还不能证明什么

关于资金：CypherpunkGuide可能通过文中链接的购买指南获得推荐佣金。本文不含直接购买商品的联盟推广链接。本次实验未接受任何钱包厂商赞助。

SLIP39是一种备份标准，把秘密信息编码为用单词记录的若干分片。附加口令（passphrase）是分片之外的另一串秘密字符；恢复目标钱包时，可能还需要它。

一套备份共有3张卡，现在只剩2张。如果采用2-of-3，也就是3份中任取2份的方案，数量可能已经足够。但仍要确认：这两张卡是否属于同一套备份，是否还需要其他组，以及打开目标钱包是否需要附加口令。

2026年10月6日，我用公开的虚拟数据运行了45个官方测试向量，也就是输入及预期结果已知的测试案例，并完成32项额外检查。全部77项都符合预期。这包括应当拒绝的输入，以及2个没有报告口令错误、却返回了不同值的案例。这个数字不代表成功恢复了77次钱包。

实验采用SLIP39的参考实现，即展示标准如何工作的程序。它没有测试硬件钱包、查找Bitcoin资金或签署交易。若要理解到账、签名与恢复能力的区别，可以先看自托管检查流程。

除了分片数量，还要数清完整的组

#

SLIP39备份可以同时规定两种要求：每组至少要有多少份分片，以及至少要凑齐多少个组。**分片（share）**是备份编码后的一部分，通常记作一串单词。**门槛（threshold）**就是相应层级要求的最低数量。

SLIP39规范定义了这两层结构。我们的分组测试备份要求3组中凑齐2组。前两组各有3份分片，每组需要2份；最后一组只有1份，拿到这一份就满足该组条件。第一组的两张卡只能凑齐一个组，仍不足以恢复整个备份。

在这套测试备份中，满足要求且不含多余分片的组合共有15种，全部恢复出预期值。另有两个不满足分组条件的案例，程序均予以拒绝。我们还单独测试了简单的2-of-3备份：3种两两组合都成功了。重复提交同一份分片，并不能增加一份独立分片。

这些分片用于重建同一份秘密信息，不是常规Bitcoin多签钱包中的独立签名密钥。多签恢复实验讨论的是另一类问题。两种方法都不一定适合每一个持有者。

分片正确，不代表附加口令正确

#

SLIP39不会验证输入的附加口令是不是你原本想用的那一个。本次故意使用错误口令的两个案例，都完成了分片恢复和解密，但输出字节与已知的公开预期值不同。

程序先重建加密主秘密（encrypted master secret，EMS），也就是分片所表示的加密值，再用附加口令导出解密结果。Trezor固件文档同样区分了分片恢复与依赖附加口令的派生过程。

因此，看到“完成”不能直接判定结果正确。我们预先知道虚拟数据的原始值，才能发现不一致；仅凭处理成功还不够。实验没有派生地址，也没有查看钱包余额。真实恢复过程中出现空钱包，需要进一步查明原因，不能仅靠这个实验就断定原因所在。

随文程序不是搜索附加口令的工具。密码恢复文章讨论的是另一类问题。

新增备份，先前的备份仍可能有效

#

为同一份秘密信息新增备份后，先前的恢复资料仍可能可用。本次测试分别用先生成的单分片备份、先生成的2-of-3备份，以及后来生成的2-of-3备份，恢复出了同一个预期值。

这里的“先前”只表示实验中的生成顺序。三套备份都采用extendable格式（extendable=True），标识符也同为42。实验没有测试旧版SLIP39格式，也没有测试设备上的升级流程。

另据Trezor的升级指南，对符合条件的现有钱包新增备份，不会使原备份失效。具体操作界面与适用条件由产品决定，本次数学示例没有测试这些条件。

检查隐私和访问控制时，除了最新备份，也要清点先前的备份。新增分片不等于撤销已经泄露的恢复资料。本文没有要求你销毁备份、重置设备或转移资金。

77项检查证明了哪些结果

#

实验把输出与预期值一致、输出不同，以及拒绝处理这三类结果分开记录。逐项结果表保留了全部77项观察。

最后两项需要限定解释。我们故意重复使用标识等元数据，让独立拆分的备份拥有相同的开头单词。这一个混合案例未通过一致性校验，但不能据此推算所有混合输入的失败率，或断言它们都会怎样处理。开头单词相同，不能证明这就是目标钱包。

超量输入遭到拒绝，是本次实现中恢复函数的限制：它要求选出数量恰好达到门槛的分片。这不意味着持有全部3份就无法恢复，因为其中每一种两份组合都已经通过测试。

实验复现包包含版本固定的官方实现、输入与结果。实验只用公开值，并固定测试随机数以便复现。绝不要把其中的分片用于真实资金，也不要修改程序来接收你的真实恢复词。 上游项目说明明确警告，这个实现没有为处理敏感秘密做安全加固。离线运行也不会让它变成可安全用于实际恢复的工具。

对于官方测试向量，我们只比对了预期的主秘密字节，没有测试其中的BIP32扩展私钥。设备兼容性、地址查找、签名，以及人实际执行恢复的流程，都不在实验范围内。

检查恢复准备，不要把秘密集中到表格里

#

恢复清单应记录哪些条件已经检查，不需要收集恢复词本身。空白检查清单只设状态栏，没有让你填写分片、附加口令、人名或存放地址的位置。

请检查备份格式及文档注明的恢复兼容性、所需分片与组数、是否另需附加口令，以及先前备份是否仍然有效。还要考虑一次事故能否同时毁掉多个存放地点。如果清单内容会透露你的安全安排，清单本身也应保密。

请按提供商针对相应产品发布的官方检查流程操作，不要为了填完表格而删除仍可用的恢复资料。文件恢复检查可以证明保存的文件可读，却不能证明文件内容满足某个钱包的恢复条件。

要点

#

关于实验结果的常见问题

#

卡片开头的单词相同，就可以组合使用吗？

#

开头单词相同，只能作为初步的元数据检查。它不能替代完整分片验证、成功重建，以及目标钱包所需条件的确认。本次开头单词相同的混合案例通过了解码，但未通过恢复时的一致性校验。

传入3份遭到拒绝，是否应该丢掉其中一份？

#

不应该。这只是本次受测恢复函数的输入要求。全部3种两份组合都恢复成功了，没有理由因此丢弃恢复资料，也不能据此认为设备界面会采用相同行为。

这个实验能证明继承安排已经妥当吗？

#

不能。它只用公开测试数据检查了一个实现，没有验证谁能找到和使用资料、相关法律权限，或持有者去世后能否继续使用。

来源与存档

#

代码仓库的存档支持其关于敏感秘密的安全警告，不是本次实验所用精确提交版本的存档。实验版本及其文件哈希包含在复现包中。