Collaborative Custody

彼得用自己的钱包管理比特币。他担心的是丢失设备或备份。钱包是接收和发送比特币的应用程序或设备。这里的签名，是用私钥这个秘密数值，生成可以验证的付款授权证明。其他人无须知道这个秘密，就能检查签名。Unchained 介绍的模式是 2-of-3：三把密钥中需要两把签名才能付款。彼得持有 A 和 B，服务方持有 C。因此 A+B、A+C 和 B+C 都有效，只有 C 则不够。这种要求多个签名的机制叫 Multisig。彼得可以不依赖服务付款，丢失一把密钥后也能求助。不过，用同一份 Seed Phrase（单词形式的备份）恢复出的两台设备并不独立：共同的秘密一旦泄露，两台设备都会受到影响。 [1] [4] [8]

只要彼得仍能使用 A+B，并保存完整的钱包资料，服务中断本身就不会剥夺他的付款能力。如果只剩 A，要使用 A+C 就必须得到服务方配合。此时，服务故障或拒绝签名都可能阻断恢复。如果 A 和 B 都丢失，单靠 C 无法救回资金。因此，独立退出与协助恢复需要分别测试。Casa 关于不依赖其基础设施的恢复说明，也明确假定服务方密钥不可用。具体流程和所需设备取决于产品，不能从“collaborative”这个词推断。 [1] [6]

彼得有备份，但替代软件还得知道该重建哪个钱包。常规 2-of-3 需要包括服务方在内的三方公钥，以及使用这些公钥的规则。公钥用于验证签名，私钥用于生成签名。Output Descriptor 是软件可读取的钱包配置说明，其中包括地址的派生方式。两份自己的 Seed Phrase 备份无法补出服务方缺失的公钥。因此，彼得应在服务正常时保存并检查导出文件。分享前还要核实内容：通用 descriptor 格式也可以包含私钥。 [4] [5]

协调器负责组织交易资料，签名方则掌握用于批准交易的密钥。BIP 174 描述的 PSBT 格式在软件与设备之间传递未完成的交易及所需数据。创建文件不会补上缺失的签名。不过，没有密钥的协调器仍可能造成危害，例如把收款人换成别人。签名前要检查地址、金额、手续费和 change，也就是返回自己钱包的剩余资金。Hardware Wallet 有助于让密钥与电脑隔离，但仍要看设备屏幕能核实什么，以及彼得实际批准了什么。 [2] [3]

错误可能在第一笔付款之前就发生，也就是软件建立共同钱包时。BIP 129 描述了密钥和配置的交换方式，让参与者能够比对签名门槛、所含密钥及首个地址。这还涉及 script 类型，即支出条件的表达方式，以及生成后续密钥的派生路径。遭篡改的设置可能把存款导向别处。但这份文件本身不涵盖设备存储的抗篡改能力，也不涵盖后续接收地址和 change 地址的验证。支持该标准不等于整个产品通过了安全认证。 [2]

XPUB 是扩展公钥，可用于派生钱包某个分支的公钥。掌握这些数据和钱包配置后，即使服务方没有足够签名来支出，也可能追踪地址与付款。如果再将它们关联到实名客户账户，就多了一层身份联系。因此，隐私与支出权限是两件事。“服务方无法单独付款”也有前提：它仍可能拿到彼得的另一把密钥，或诱使他签署有害交易。缩小服务方权限可以降低部分风险，但不会消除全部风险。 [2] [4]

彼得丢失了一把密钥，于是在软件里创建新密钥。这不会让旧密钥对以前的存款失效。交易输出记录一笔金额，以及之后花费这笔金额必须满足的条件。那些资金以 UTXO 存在，也就是尚未花费、各自带有支出条件的交易输出。对于常规 Multisig，需要建立新条件，并通过已确认交易把相关资金转移过去。之后还要检查旧地址上是否有余额。修改账户密码或密钥标签不能替代这次转账。配置和家庭说明也必须更新，否则继承人可能拿着已经与实际资金不符的计划。 [4] [9]

有意义的演练应使用独立的测试钱包。彼得将已保存配置导入兼容软件，比对地址，确认无需原服务也能用自己的密钥签名。Watch-only 模式显示地址和余额，却不能证明具备签名能力。Caravan 是一个开源协调器，但仍需核实其对具体格式和设备的支持。演练还应覆盖协助恢复、某把密钥不可用、手续费和 change。最终应得到清楚的书面流程及所用软件版本，而不只是看到余额后产生的安心感。 [3] [6] [7]