本期 Newsletter 描述了一个新的契约操作码提案，并总结了在 signet 上实施定期重组（reorg）的反馈请求。同时包含我们关于如何为 taproot 激活做准备的常规章节、新版本发布列表以及主流比特币基础设施软件的更新说明。

新闻

  • ● 契约操作码提案： Anthony Towns 在 Bitcoin-Dev 邮件列表发布了关于新契约操作码的概述，以及更技术细节的说明，描述该操作码（及其他 tapscript 变更）的工作原理。

    简而言之，新操作码 OP_TAPLEAF_UPDATE_VERIFY（TLUV）会获取被花费的 taproot 输入信息，根据 tapscript 描述的修改规则，要求结果必须与输出中对应位置的 scriptPubKey 等效。这使得 TLUV 能够约束比特币的支出路径（即契约的定义），类似于其他提案如 OP_CHECKSIGFROMSTACK（CSFS）和 OP_CHECKTEMPLATEVERIFY（CTV）。其独特之处在于允许 tapscript 创建者进行以下修改：

    • ● 内部密钥调整： 每个 taproot 地址都承诺一个可用于直接签名的内部密钥。要使用 tapscript（包括 TLUV），需公开当前内部密钥。TLUV 允许指定对该密钥的调整。例如，若内部密钥是 A+B+C 的聚合密钥，可通过 -C 调整移除密钥 C，或通过 X 调整添加密钥 X。TLUV 会计算调整后的内部密钥，并确保输出支付到该密钥。

      Towns 在邮件中描述了一个强大用例：更高效地创建 joinpool —— 一个由多个用户共享的 UTXO，每个用户控制部分资金且无需在链上公开所有权信息（也不暴露所有者数量）。若所有成员联合签名，他们可以进行高度可互换的交易。若存在分歧，每个成员可通过交易随时退出（仅需支付链上交易费）。

      当前使用预签名交易也可创建 joinpool，但若希望每个成员能独立退出而不依赖他人协作，则需要指数级增长的签名数量。CTV 存在类似问题，退出可能需创建影响其他用户的多笔交易。而 TLUV 允许单个成员随时退出，无需预签名且不影响其他用户（仅需公开该成员已退出）。

    • ● 默克尔树调整： taproot 地址也可承诺 tapscript 树的默克尔根。TLUV 允许脚本指定如何修改默克尔树。例如，可移除当前执行的节点（如成员退出 joinpool），或替换为支付不同 tapscript 的节点。TLUV 会计算调整后的默克尔根，并确保输出支付到该根。

      Towns 的邮件描述了如何利用此功能实现 Bryan Bishop 2019 年的保险库设计（参见 Newsletter #59）。Alice 创建两对密钥：热钱包（低安全性）和冷钱包（高安全性）。冷钱包密钥作为 taproot 内部密钥，可随时花费资金。热钱包密钥结合 TLUV 仅允许将资金花费到包含时间延迟的默克尔树修改（延迟后热钱包密钥才能发起二次支出）。

      这意味着 Alice 可用热密钥发起资金支出，但需创建链上交易并等待时间延迟（如 1 天）完成后才能真正转账。若他人盗用热密钥发起支出，Alice 可用冷密钥将资金转移至安全地址。

    • ● 金额自省： 除 TLUV 外，新增第二个操作码将输入及其对应输出的比特币金额推送到脚本执行栈，允许通过数学和比较操作码限制可支出金额。

      在 joinpool 场景中，这可确保退出成员仅能提取自身资金。在保险库场景中，可设置周期性提款限额（如每日 1 BTC）。

    截至撰稿时，该提案仍在邮件列表接收初步反馈。我们将在未来 Newsletter 中总结值得注意的评论。

  • ● Signet 重组讨论： 开发者 0xB10C 在 Bitcoin-Dev 邮件列表发布关于在 signet 实施定期区块链重组（reorg）的提案。将被重组的区块会在版本字段的某一位发出信号，使不希望跟踪重组者能忽略这些区块。重组将定期发生（约每日三次），并遵循两种模拟主网可能重组模式的方案。

    0xB10C 已收到多条反馈。我们鼓励对测试 signet 重组（或希望避免重组）的读者参与讨论。

准备 Taproot #13：备份与安全方案

关于开发者和服务提供商如何为即将在区块高度 709,632 激活的 taproot 做准备的系列文章。

上周专栏中，Antoine Poinsot 描述了 taproot 如何提升保险库式资金备份与安全方案的隐私性和手续费效率。本周我们将探讨其他几种可通过迁移至 taproot 获得改进的备份与安全方案。

  • 简单 2-of-3： 如前文所述，结合多签和脚本路径支出，可轻松创建 2-of-3 支出策略。正常情况下其链上效率与单签支出相当，且比当前 P2SH 和 P2WSH 多签方案更隐私。异常情况下的效率和隐私性也表现良好。这使 taproot 成为从单签钱包升级到多签策略的理想选择。

    我们预计未来的门限签名技术将进一步优化 2-of-3 及其他 k-of-n 场景。

  • 降级多签： Optech Taproot 研讨会中的练习可体验创建支持以下规则的 taproot 脚本：随时由三个密钥支出；三天后由原密钥中的两个支出；十天后仅需一个原密钥（该练习还涉及备份密钥，我们将在下一点单独讨论）。调整时间参数和密钥设置可构建灵活强大的备份方案。

    例如，假设正常支出需笔记本电脑、手机和硬件签名设备三者协同。若其中一设备不可用，等待一个月后可用剩余两设备支出。若两设备不可用，六个月后仅需一设备即可支出。

    正常三设备协同使用时，链上脚本实现最高效和隐私。其他情况下效率略降但仍保持合理隐私性（脚本及其树深与其他合约相似）。

  • 社交恢复备份与安全： 上述示例在设备被盗时提供良好保护，但若两设备同时被盗呢？若钱包使用频繁，设备丢失后需等待一个月才能恢复支出是否合理？

    taproot 可便捷、低成本且隐私地添加社交元素。除上述脚本外，还可允许：两设备加两位亲友签名即时支出；或单一密钥加五位信任者签名即时支出（非社交版本可使用额外设备或备份助记词）。

  • 时间与社交阈值结合的继承方案： 综合上述技术，可设置在你突发意外时允许指定个人或群体恢复资金。例如，若比特币六个月未移动，允许律师和五位亲属中的三位支出。若你本就每六个月操作资金，该继承方案在你生前无额外链上成本且对外完全隐私。甚至可让律师和亲属在你生前无法知晓交易详情（只需确保他们能在你离世后获取钱包的扩展公钥 xpub）。

    请注意，继承人具备技术能力支出比特币不等同于合法继承。建议计划比特币继承者阅读 Pamela Morgan 的《加密资产继承规划》（实体书/DRM 电子书 或 DRM-free 电子书），并与本地遗产规划专家讨论细节。

  • 入侵检测： taproot 诞生前提出的树签名方案建议在所有设备上放置控制少量比特币的密钥作为入侵检测。若金额足够诱人，攻击者可能选择立即盗取而非长期潜伏造成更大损失。

    该方案的挑战在于：需设置足够吸引攻击者的金额，但又不愿在每台设备存放大量比特币（希望仅提供一份高额赏金）。若所有设备使用相同密钥，攻击交易无法定位被入侵设备。taproot 允许为每台设备设置不同密钥和脚本路径。任一密钥均可支出全部资金，同时精确定位被入侵设备。

发布与候选发布

主流比特币基础设施项目的新版本和候选版本。请考虑升级或协助测试。

值得注意的代码与文档变更

本周 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口（HWI）、Rust Bitcoin、BTCPay Server、比特币改进提案（BIPs）和闪电网络规范（BOLTs）的显著变更。

  • ● Bitcoin Core #22079 为 ZMQ 接口添加 IPv6 支持。

  • ● C-Lightning #4599 实现了 BOLTs #843 描述的快速关闭手续费协商协议。我们曾在上周 Newsletter 描述该协议，但对其替代的旧协议描述存在误差。旧协议需基于试错的费率协商，且不允许设置高于当前承诺交易的手续费率。这在锚定输出场景下不合理（低费率承诺交易设计为可追加手续费）。新协议允许支付更高费用，并在可能时使用更高效的区间协商。Eclair #1768 也于本周合并实现该协议。

  • ● Eclair #1930 允许其路径查找算法使用非默认实验参数集。可通过自动分配部分流量或 API 手动执行。各参数集的指标单独记录，用于优化最佳参数。

  • ● Eclair #1936 允许禁用节点 Tor 洋葱服务地址的公开，以保护地址隐私。

  • ● LND #5356 新增 BatchChannelOpen RPC，支持在单笔批量支付交易中向不同节点开通多个通道。

  • ● BTCPay Server #2830 新增支持创建启用 taproot 的钱包，可收发单签 P2TR 支付（已在 signet 测试）。合并的 #2837 在钱包设置中列出 P2TR 地址支持，但在区块 709,632 前暂不可选。