比特币正本 Bitcoin Arche

协议演进 / BIP/比特币改进提案 / BIP-129

BIP-129 比特币安全多签设置（BSMS）

用协调者加签名者的两轮加密交换，安全地建立跨厂商多签钱包，并让每位签名者核对并保存同一份描述符配置。本 BIP 目前处于已完成状态。

一、档案卡

档案卡
编号BIP-129
标题Bitcoin Secure Multisig Setup (BSMS)
作者Hugo Nguyen <[email protected]>, Peter Gray <[email protected]>, Marko Bencun <[email protected]>, Aaron Chen <[email protected]>, Rodolfo Novak <[email protected]>
指定日期2020-11-10
层级Applications（应用）
类型Specification（规范类）
状态Complete（已完成）
前置依赖BIP-32, BIP-174, BIP-322, BIP-380, BIP-381, BIP-382, BIP-383
阅读版https://bips.dev/129
官方原文https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki

二、放在哪一族

多签钱包建立与描述符族。BIP-174（PSBT）把多签的“签一笔交易”流程标准化了，本 BIP 补的是它前面缺的一环：多签钱包本身最初怎么在不同厂商的设备之间安全地建起来。

它的前置依赖（Requires）构成一条清晰的链：

BIP-32：分层确定性密钥，签名者提供的 KEY/XPUB 来自它

BIP-174：PSBT，多签交易协作的既有标准

BIP-322：通用签名消息格式，密钥记录里的 SIG 用它（也接受 legacy 格式）

BIP-380、BIP-381、BIP-382、BIP-383：输出脚本描述符，BSMS 的配置记录就用描述符（或描述符模板）表达

它在钱包协调族里的位置是“建钱包”而不是“花钱包”：产出物是一份所有签名者都核对过、并各自保存的描述符记录，此后生成与核验收款、找零地址才有共同依据。

三、它要解决什么

原文列出多签设置阶段的五类关切：

  1. 多签配置是否正确、未被篡改——包括签名者成员、脚本类型、派生路径与所需签名数（M-of-N）；
  2. 密钥或配置会不会在设置过程中泄漏；
  3. 签名者是否把配置存进各自存储、以什么格式存；
  4. 签名者的存储是否防篡改；
  5. 签名者之后是否真的用这份配置生成并核验收款与找零地址。

攻击者若能修改配置，可把用户骗去向错误地址打款，盗走资金或以此勒索；若不能改、但能学到密钥与配置，则可监控钱包全部交易，损失隐私。

本 BIP 只负责处理前三项：降低初始设置阶段被篡改的风险，并定义一个可互操作的多签配置格式。第 4、5 项由各签名者自行负责，不在本提案范围内——读它时不要期待它保证设备存储安全或后续地址核验。

四、规则本身

4.1 角色与前置约定

协调者（Coordinator）：发起设置。它决定多签类型与确切的策略脚本；启用加密时，由它向各方分发共享秘密；它收集各签名者的信息生成描述符记录，再把记录分发回各签名者。

签名者（Signer）：任何控制私钥、能用私钥签名的软件或硬件，是多签的参与成员。它要向协调者提供密钥记录（内含公钥或扩展公钥 XPUB），核查自己的 KEY 确实被包含进描述符记录，并把描述符记录存入自己的存储。

前置假设：参与方都支持 BIP-32、BIP-322、描述符系列（BIP-380 至 BIP-383）与 AES 加密（RFC 3686）。文件约定：描述符与密钥记录用 .bsms 扩展名，加密数据用 .dat；换行一律用 LF（\n）。本节所述版本号为 BSMS 1.0。

4.2 第一轮：签名者交密钥记录

协调者先新建一个多签钱包创建会话，构造多签脚本及其策略参数（所需签名数 M 与签名者总数 N）。会话应在一个由协调者决定的时限后过期（例如 24 小时），时限的存在让加密密钥可以容忍较低的熵。启用加密时，协调者通过安全通道向每个签名者分发一个秘密 TOKEN（可全员共用一个，也可每人一个）；不加密时 TOKEN 设为 0x00，后续加解密步骤全部跳过。

签名者以设置 TOKEN 开始会话，并由 TOKEN 派生 ENCRYPTION_KEY。签名者让用户给出多签派生路径、取出该路径的 KEY（也可由签名者代选路径，但应尽量避免不同钱包复用同一 KEY），然后按固定五行的格式生成密钥记录：

  1. 规范版本：BSMS 1.0；
  2. TOKEN 的十六进制编码；
  3. KEY：公钥或 XPUB，连同密钥来源信息，按描述符格式写成 [{主密钥指纹}/{派生路径}]{KEY}；
  4. 该密钥的文字说明，最长 80 字符；
  5. SIG：用与该公钥或 XPUB 对应的私钥，对前四行内容按 BIP-322 所作的签名（接受 legacy 格式）。

随后签名者为记录计算 MAC，以 MAC 的前 16 字节作为加密的 IV，用 ENCRYPTION_KEY 加密记录，再把 MAC 与密文都编码为十六进制并拼接为 (MAC || ciphertext) 交出。

4.3 第二轮：协调者发描述符记录

协调者收集全部签名者的密钥记录，在会话过期前核对恰好有 N 份互不相同的记录。对每份记录：取出 MAC、以其前 16 字节为 IV 解密；验证 MAC 对明文有效；验证各记录的规范版本兼容；验证 SIG 对 KEY 有效。全部通过后，协调者生成描述符记录，同样是固定格式：

  1. 规范版本：BSMS 1.0；
  2. 一个描述符，或一个描述符模板（见 4.5）；
  3. 逗号分隔的派生路径限制列表，路径以 / 开头、使用非硬化派生；若没有模板或限制，必须写 No path restrictions；
  4. 钱包的第一个地址；有路径限制时，用第一条路径限制对应的第一个地址。

协调者同样为该记录计算 MAC、取前 16 字节为 IV、加密，再以 (MAC || ciphertext) 的十六进制拼接形式发给全部签名者。

签名者收到后：导入并解密，验证 MAC、版本与描述符是否可支持；必须逐字精确核对自己的 KEY 被包含在描述符或模板中（用路径与指纹信息做精确匹配，不能只比对指纹这类容易伪造的捷径）；核对派生路径限制可兼容、第一个地址有效。确认环节中，签名者必须向用户展示钱包的第一个地址与策略参数，包括派生路径限制、M、N 以及自己的 KEY 在策略脚本中的位置（N 很重要，防 KEY 插入攻击；位置对顺序敏感的脚本重要，同一 KEY 的全部位置都要展示）；完整描述符须可应用户要求调阅。各方还要互相核对：除各自 KEY 的位置外，所有签名者看到的确认信息应当一致。全部检查通过，签名者必须把描述符记录存入自己的存储。至此设置完成。

4.4 加密：TOKEN、密钥派生与算法

TOKEN 有三种模式：NO_ENCRYPTION，TOKEN 为 0x00，禁用加密；STANDARD，TOKEN 是 64 位 nonce；EXTENDED，TOKEN 是 128 位 nonce。TOKEN 可表示为十进制数（推荐，不得超过 nonce 上限）、用 BIP-39 词表编码的助记短语（STANDARD 模式为 6 个词；EXTENDED 模式不推荐，容易与种子助记词混淆）、二维码或其他格式。

密钥派生用 PBKDF2，PRF 为 SHA512：Password = “No SPOF”，Salt = TOKEN，迭代次数 c = 2048，输出 dkLen = 256 位（32 字节），得到 ENCRYPTION_KEY。

加密方案为 AES-256-CTR（RFC 3686）。MAC = HMAC-SHA256(HMAC_Key, 十六进制编码的 TOKEN || 数据明文)，其中 HMAC_Key = SHA256(ENCRYPTION_KEY)；IV 取 MAC 的前 16 字节。MAC 随记录一同发送；由于它是对全部明文的 MAC，这本质上是 Encrypt-and-MAC 形式的认证加密。

TOKEN 只在设置阶段需要，用后可安全丢弃；原文不推荐把同一 TOKEN 用于多个钱包创建会话。想加强隐私，可用更多比特的 TOKEN，并在设置完成后彻底 erase 对 TOKEN 的记忆。

4.5 描述符模板：把一维列表扩成多维

输出描述符语言只支持一维列表，本 BIP 引入描述符模板来表达多维列表：在 XPUB 后写 /**，即 XPUB/**，其中 /** 可被任意条派生路径限制替换。模板必须伴随路径限制给出，签名者把 /** 依次替换为各条限制，展开为具体描述符。原文例子：模板 wsh(sortedmulti(2,XPUB1/**,XPUB2/**)) 配限制 /0/*,/1/*，展开为两条具体描述符，分别是把 /** 换成 /0/* 与 /1/* 的结果。

用二维码传输记录时，原文指向 Blockchain Commons 的 BCR 标准将记录转为二维码。

4.6 兼容性

本规范与既有多签实现不向后兼容（not backwards compatible）。BSMS 是 opt-in 的：既有实现可以照旧工作，只是很可能带有第三节所述的各种隐患。要合规，签名者必须能把描述符记录存入自己的存储；用户应等到多签的全部参与签名者都实现了 BSMS，再用它建钱包。

五、谁必须动

普通持币人（多签用户）：建钱包时要参与确认环节——核对每个签名者展示的第一个地址与 M、N 等策略参数是否一致，并保管好各设备对配置的确认结果；不要跳过跨设备互核这一步，它正是防篡改的第二层防线。

协调者软件开发者：要实现会话与过期、TOKEN 分发、第一轮记录的逐项验证（MAC、版本、SIG）、描述符记录的生成与加密分发。

签名者（硬件/软件钱包）开发者：要实现密钥记录的五格格式与 BIP-322 签名、加解密与 MAC、第二轮的精确 KEY 匹配与地址核验、向用户展示确认信息，并把描述符记录持久化保存。

全节点与矿工：不必动。BSMS 全程发生在链下，不产生特殊交易。

共识层：无改动。多签脚本本身沿用既有脚本与描述符标准。

六、现在算不算数，以及一个常见误读

状态为 Complete（已完成）。按仓库状态解释：规范文本已经定稿完整，可供厂商实现与互操作测试；它不是需要全网激活的协议升级，“完成”指文档成熟度，不等于所有多签产品都已支持——原文自己就把使用条件写明了：应等全部参与签名者都实现 BSMS 后再用它建钱包。本页不臆测具体产品的支持情况。

常见误读：“用了 BSMS 建的多签钱包，配置就绝对不会被动手脚。”

不对。BSMS 提供的是两层防护：临时秘密 TOKEN 对两轮通信加密并做 MAC 认证，以及各方对钱包第一个地址与策略参数的交叉确认。原文的安全模型恰恰依赖用户真的去核对：攻击者若篡改配置，必须同时改掉第一个地址，各方互核同一地址与参数才能把篡改概率压低。跳过确认环节，等于主动卸掉第二层防护；而且存储防篡改与后续地址核验本就不在本 BIP 范围内。

七、延伸

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。