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

BIP-124 分层确定性脚本模板

用 BIP32 派生路径加脚本模板的统一记法，让不同钱包对同一授权策略确定性地生成完全相同的脚本。本 BIP 目前处于已关闭状态。

一、档案卡

二、放在哪一族

钱包脚本构造与互操作族。它站在 BIP-32（分层确定性钱包）的密钥派生之上，想再往上统一一层：脚本本身怎么由派生路径确定性地拼出来。

它直接引用的前置与配套包括：

BIP-16：Pay to Script Hash，当时最常见的多签承载方式

BIP-32：分层确定性派生，本 BIP 的密钥来源

BIP-65：OP_CHECKLOCKTIMEVERIFY，哈希锁与时间锁合约的构件之一

BIP-112：CHECKSEQUENCEVERIFY，另一构件

原文还把 Lightning Network 白皮书列为参考文献：多层协议把区块链当结算层，正是它想服务的复杂脚本场景。后来钱包间交换脚本构造方式的实际工作，更多沿输出脚本描述符一族展开（见 BIP-380 起的描述符系列，以及 BIP-129 的多签设置）——但那是后来的路线，本 BIP 本身停在 Closed，不能把后来的成果算作它的采用。

三、它要解决什么

3.1 各钱包各写各的脚本

原文指出，当时钱包发出的脚本只有极少数广泛使用的格式，最常见的是 pay-to-pubkey-hash 与 m-of-n 的 pay-to-script-hash（BIP-16）。问题是：不同钱包用互不兼容的派生方案生成签名密钥、再构造脚本。同一套授权策略，换一个钱包就拼不出同一份脚本，更谈不上多家钱包协作。

3.2 脚本正在变复杂

随着哈希锁、时间锁合约（BIP-65、BIP-112）出现，不同钱包需要能协作生成更精巧的脚本；同时，把区块链当结算层的多层协议（例如 Lightning Network）也在发展，需要足够通用的模板，才能跟上快速演进的脚本设计。

本 BIP 的目标因此很具体：给出一套通用格式，保证不同钱包对同一组 BIP32 派生路径，产出的脚本完全一致。

四、规则本身

4.1 密钥：派生路径加自由索引

单个密钥由一条 BIP32 派生路径和一个索引 k 确定，记法为 A_k =（A 的派生路径）/k。同一个模板换不同的 k，就得到同一策略下的一系列脚本——这正是“确定性”的含义：路径与索引定了，脚本就定了。

4.2 密钥组与排序

设 m_1、m_2、…、m_n 为互不相同的 BIP32 派生路径，密钥组是共享同一个自由索引 k 的一组路径：{ m_1/k, m_2/k, …, m_n/k }。

密钥组适用于对一组密钥“对称”的脚本：脚本语义不因密钥排列顺序改变时，用密钥组能强制一种规范形式，并改善隐私。

原文还定义了密钥的字典序排序，并用下标 j 表示排序后第 j 个密钥。但要如实说明：排序的具体约定（压缩公钥、编码等）在原文里仍标着 TODO，编码一节也整节是 TODO。这份文档本身就没有写完。

4.3 脚本模板：在操作码里留占位符

模板的写法是把数据占位符插进脚本：Script(A) = 操作码 [A] 操作码，可扩展到任意多个占位符 Script(X1, X2, …, Xn)。排序后的密钥组有简写 [{K_k}]，依次展开为组内各密钥的占位符。

有时要放进脚本的不是密钥本身，而是对密钥做运算的结果，例如 Hash160(A_k)，记法为 [Hash160(A_k)]。

4.4 三个例子

2-of-3 多签：模板为 2 [X] 3 OP_CHECKMULTISIG，其中 X 是含三条路径的密钥组，第 k 个脚本记为 Script({K_k})。

1-of-1 或 2-of-3：超级用户密钥 M_k 单独签名即可花费（OP_DUP [A] OP_CHECKSIG 一支）；否则走 2-of-3 的 OP_CHECKMULTISIGVERIFY 一支，模板里用 OP_NOTIF / OP_ENDIF 组织这两条路径。

时间锁合约：Alice 知道 A_k 的私钥即可立即花费；Bob 除了要知道 B_k 的私钥，还必须等超时 t 之后。模板用 OP_IF / OP_ELSE 分开两支：Alice 一支是 Hash160 校验加 OP_CHECKSIG，Bob 一支先过 [T] OP_CHECKLOCKTIMEVERIFY OP_DROP，再做同样的 Hash160 校验与签名。

五、谁必须动

普通持币人：无直接变化。本 BIP 不改交易格式、地址或共识规则。

钱包开发者：若要实现，需按同一套记法与规范形式，从 BIP32 派生路径生成密钥、密钥组与模板脚本，保证与别家钱包逐字节一致。但原文排序与编码两处未完成，照原文无法独立做出可互操作的完整实现。

全节点与矿工：不必动。模板生成的仍是普通脚本，节点验证方式不变。

共识层：无改动。它借用的 OP_CHECKLOCKTIMEVERIFY、OP_CHECKSEQUENCEVERIFY 等能力来自各自的 BIP，不在本 BIP 内新增。

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

状态为 Closed（已关闭）。按仓库状态解释：这份信息类文档的提案进程已经结束，不再是现行有效的推荐文本。它提出的“模板加派生路径”问题意识——钱包必须能互操作地构造复杂脚本——后来由其他文档以不同形式承接，但不能反过来说本 BIP 已被部署或采用。原文自身也有未完成处：排序约定与编码两节留着 TODO，这是读它时必须知道的事实。

常见误读：“有了 BIP-124，各钱包就能按同一模板生成多签和时间锁脚本了。”

不对。原文只定义了密钥、密钥组与模板的记法框架，排序约定和编码都没有写完，状态又是 Closed。它是一份未完成的格式草案，价值在于把问题提清楚，而不是一份可以照着实现的产品规范。

七、延伸

• 阅读版：https://bips.dev/124
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0124.mediawiki
• 相关：BIP-32 分层确定性钱包、BIP-16 P2SH、BIP-65 OP_CHECKLOCKTIMEVERIFY、BIP-112 CHECKSEQUENCEVERIFY
• 仓库总目录：https://github.com/bitcoin/bips

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