比特币正本 Bitcoin Arche

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

BIP-360 Pay-to-Merkle-Root（P2MR）

提出只保留脚本树、去掉密钥路径花费的新输出类型 P2MR，让 Taproot 式脚本树免受公钥长期暴露的量子攻击。本 BIP 目前处于草案状态。

一、档案卡

档案卡
编号BIP-360
标题Pay-to-Merkle-Root (P2MR)
作者Hunter Beast <[email protected]>, Ethan Heilman <[email protected]>, Isabel Foxen Duke <[email protected]>
指定日期2024-12-18
层级Consensus (soft fork)（共识（软分叉））
类型Specification（规范类）
状态Draft（草案）
依赖BIP-340, BIP-341, BIP-342
阅读版https://bips.dev/360
官方原文https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki

二、放在哪一族

Taproot 家族的改型，也是量子防御族的第一步提案。它几乎整体复制 BIP-341（Taproot）与 BIP-342（Tapscript）的机制，只删一样东西：密钥路径花费。

同族关系：

BIP-340：Schnorr 签名，P2MR 叶子脚本里仍在用

BIP-341：Pay-to-Taproot（P2TR），P2MR 的原型——同样的脚本树、同样的 TapBranch 哈希，区别在输出承诺的东西不同

BIP-342：Tapscript 验证规则，P2MR 花费时直接沿用

BIP-361：后量子迁移与旧签名退役，着眼的是全网迁移时间表；BIP-360 着眼的是先给想要自保的用户一种可用的输出类型，两者互补

原文把 P2MR 称为“脚本树输出类型”：若激活，它将是比特币第二种支持脚本树与 Tapscript 的输出类型，第一种是 P2TR。

三、它要解决什么

对比特币的量子威胁，核心是 Shor 算法：足够强的、与密码学相关的量子计算机（原文缩写 CRQC）能高效求解离散对数问题，从公钥反推私钥。原文先把攻击分成两类，这是理解全篇的钥匙：

现有输出类型里，P2PK、裸多签（P2MS）与 P2TR 对长期暴露是脆弱的：P2TR 的输出本身就是一个（微调过的）公钥，明晃晃地摆在链上。而哈希型的 P2PKH、P2SH、P2WPKH、P2WSH 在脚本不揭示前不暴露公钥，对长期暴露不脆弱（原文加星号提醒：一旦花费揭示了公钥或脚本，情况会变）。麻烦在于：P2TR 是目前唯一支持 Tapscript 与脚本树的已激活输出类型，想要脚本树功能，就得接受公钥长期暴露。

动机部分还提到，即便不论 CRQC 何时到来，监管与机构的时间表已经在动：原文举了 CNSA 2.0 要求 2030 年前升级后量子方案、NIST IR 8547 计划 2035 年后在美国联邦政府内禁用椭圆曲线密码等例子，认为“用户对量子计算机的担忧本身”就值得用低风险的小改动来回应。

本 BIP 只解决长期暴露这一半，而且只针对脚本树场景；短期暴露要靠未来引入后量子签名，那是后话。

四、规则本身

4.1 输出：只承诺默克尔根

P2TR 的输出是“内部公钥经脚本树默克尔根微调后的公钥”。P2MR 把内部公钥整个去掉：输出直接承诺脚本树的默克尔根——按 BIP-341 的方法用 TapLeaf、TapBranch 标签哈希逐层算出的 tapbranch 根哈希，就这么一个 32 字节哈希，没有微调步骤。

叶子脚本里当然仍可以放公钥或公钥哈希，原文说得清楚：被拿掉的是输出层那个长期暴露的公钥，不是脚本里的签名检查。

新输出占用 SegWit 版本 2：scriptPubKey 为 OP_2 OP_PUSHBYTES_32 <32 字节默克尔根>。按 BIP-173 的 Bech32m 编码，版本 2 对应前缀字符 z，主网地址以 bc1z 开头。

4.2 花费与验证：BIP-341 脚本路径的删减版

花费见证的结构与 P2TR 脚本路径花费相同：初始栈元素、叶子脚本、控制块。两处删减：

验证流程基本照抄 BIP-341 的脚本路径：从叶子脚本算 tapleaf 哈希，沿控制块里的默克尔路径逐层用 TapBranch 哈希折算出根 r，与输出中的见证程序 q 比对，一致才执行脚本；脚本执行规则用 BIP-342，签名消息构造也与 BIP-342 的 Common Signature Message 完全相同。

一条兜底差别：深度为 0 的脚本树（整棵树只有一个叶子）在 P2MR 里视为 anyone-can-spend——验证到根对上就直接成功，不执行脚本。这是刻意的：既不鼓励今天用单叶子树（那等于没给未来的后量子叶子留位置），又把深度 0 留作未来软分叉可重定义的口子。

4.3 设计取舍

为什么不直接用 P2WSH？ 因为 P2WSH 不支持 Tapscript，也就没有 OP_SUCCESSx 这条升级通道；将来若要以操作码形式引入后量子 CHECKSIG，脚本树是更现实的载体。

为什么鼓励至少深度 1？ 让每个 P2MR 地址至少有两条花费路径，为将来塞入一条后量子叶子预留结构，也让它的隐私轮廓与 P2TR 接近：花费任意叶子只泄露叶子总数的下限，未用路径始终不揭示，这点比 P2SH 强。

体积账：输出大小与 P2TR 相同。输入方面，P2MR 永远走脚本路径，比 P2TR 密钥路径花费的见证大（原文算例：深度 1 时见证 135 字节，对 66 字节，多 69 字节；一般式多 37 + 32*m 字节左右）；但比等价的 P2TR 脚本路径花费小 32 字节——省掉的正是控制块里的内部公钥。计算开销上，P2MR 验证是 P2TR 脚本路径验证的严格子集，略快。

安全性口径：默克尔根是 256 位哈希，抗碰撞 128 位、抗原像 256 位，与 P2WSH 同级。但原文强调：防住长期暴露的前提是用户自己不通过地址复用等方式另行暴露公钥；xpub 与钱包描述符泄漏的公钥信息同样在攻击面内。

4.4 与后量子签名的关系

本 BIP 本身不引入任何后量子签名算法。它做的是把“地基”先打好：一种不受长期暴露之害、又支持 Tapscript 的输出类型。将来若后量子签名经新叶子版本或 OP_SUCCESSx 引入，P2MR 的树里可以加一条后量子叶子，届时才谈得上对短期暴露的防护。原文对 ML-DSA、SLH-DSA 等候选算法只作了审慎提示，要求在采用前充分审查，本篇不选型。

五、谁必须动

普通持币人：现在什么都不用动——这是草案，未激活，bc1z 地址在今天的主网上没有 P2MR 含义。将来若激活，想获得长期暴露防护的用户才需要把资金从 P2TR 迁到 P2MR，并改用脚本路径花费；只用 P2TR 密钥路径的钱包用户，迁移路径是换成一条简单的 OP_CHECKSIG 叶子脚本。

钱包开发者：复用现有 Taproot/Tapscript 代码，新增 P2MR 输出的构造（算默克尔根、拼控制块）与花费；特别要处理深度 0 即 anyone-can-spend 这条与直觉相反的规则。

全节点与矿工：属于软分叉提案，激活需要节点升级实现 SegWit 版本 2 的新验证规则。未升级节点会把 P2MR 输出看成 anyone-can-spend（这正是软分叉的兼容方式），原文称旧节点一般不会转发或打包这类交易，未升级钱包也可能无法正确收付。

共识层：本 BIP 本身就是共识层提案，动的是输出验证规则；但它的手法是新增一种输出类型，不改动 P2TR 等既有类型的任何规则。

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

状态为 Draft（草案），版本还在 0.12.x 迭代（原文变更记录显示名称从 P2QRH、P2TSH 一路改到 P2MR，见证版本也从 3 改到 2）。它没有激活、没有部署时间表，现在不算数：任何今天发往 bc1z 样式地址的资金都不受本 BIP 保护。读它是为了看清量子防御讨论中“改动最小的第一步”长什么样。

常见误读：“P2MR 是后量子输出，用了它就量子安全了。”不对。P2MR 删掉的只是输出层长期暴露的那个公钥，防的仅是长期暴露攻击；叶子脚本里用的仍是 ECDSA/Schnorr 一类椭圆曲线签名，花费时公钥照样要在内存池窗口里短暂暴露，短期暴露攻击它防不了——那需要另行引入后量子签名，本 BIP 明确没有包含。把它理解为“先拆掉最容易被慢慢算的那颗雷”，而不是“量子防护已完成”。

七、延伸

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