本周的 Newsletter 概要介绍了两个关于钱包支持 taproot 的提案 BIP，并且包含我们常规的部分，描述了 Bitcoin Stack Exchange 精选问答、如何为 taproot 做准备，以及对常用比特币基础设施项目的值得注意的更改。

新闻

• ● PSBT 扩展以支持 taproot：Andrew Chow 通告一个提案 BIP到 Bitcoin-Dev 邮件列表，用于定义新的字段以便在PSBTs 花费或创建 taproot 输出时使用。该提案为原始版本 0 PSBT 和提议的版本 2 PSBT（参见 Newsletter #128）都扩展了字段，支持密钥路径（keypath）和脚本路径（scriptpath）两种花费方式。

  该提案还建议，PSBT 中的 P2TR 输入可以省略之前交易的副本，因为 taproot 修正了针对 v0 segwit 输入的手续费超额支付攻击（参见 Newsletter #101）。

• ● 单签名 P2TR 的密钥派生路径：Andrew Chow 还向 Bitcoin-Dev 邮件列表通告了一个提案 BIP，建议为创建单签名 taproot 地址的钱包使用一个 BIP32 派生路径。Chow 指出，此 BIP 与用于 P2SH-wrapped P2WPKH 地址的 BIP49 以及用于原生 P2WPKH 地址的 BIP84 十分相似。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者们第一时间寻找问题答案的地方之一——或者当我们有空时，我们也乐于帮助好奇或困惑的用户。在这个月度专题中，我们会挑选一些自上次更新以来投票数较高的问题和答案进行重点介绍。

• ● 在未来软分叉中启用可能次优或未使用的 opcode 有哪些弊端？ G. Maxwell 概述了启用任何会影响共识的 opcode 所要考虑的诸多因素，包括：

  • 前期及持续维护成本

  • 对使用该 opcode 的用户以及整个网络带来的潜在风险

  • 附加的复杂性让定制或重新实现节点软件的行为门槛更高

  • 部分或低效的特性会挤占将来更好替代方案的空间

  • 意外产生反常激励

• ● 为什么区块范围内的签名聚合会阻止签名适配器？ Pieter Wuille 解释了为什么跨输入签名聚合会干扰类似签名适配器或无脚本脚本（scriptless scripts）等技术，指出：“在区块范围内的签名聚合场景下，整个区块只有一个签名。这使得该唯一签名无法向多个独立的当事方分别揭示多个独立的秘密。”

• ● Bitcoin Core 钱包（或任意钱包）是否应该阻止用户在激活前将资金发送到 Taproot 地址？ Murch 阐述了为什么钱包软件应该允许用户向任何未来的 BIP173 segwit 输出类型发送资金。通过让接收方负责提供可支配的地址，整个生态可以利用 bech32/bech32m 的前向兼容性，并即时使用新的输出类型。

• ● 为什么 schnorr 签名仍然使用隔离见证？ Dalit Sairio 问道，既然 schnorr 签名不会像 ECDSA 签名那样遭受同样的易变性问题，为什么它们仍然会被隔离出来？Darosior 指出，易变性只是隔离见证带来的诸多好处之一。Pieter Wuille 补充说，签名易变性只是更广泛的脚本易变性的一部分而已。

• ● MuSig 可以支持多少个签名者？ Nickler 解释道，对于 MuSig 与 MuSig2，签名者的数量在实践中几乎是无限的，他还提到自己的基准测试显示，在笔记本电脑上 100 万个签名者花费了大约 130 秒。

• ● 对 P2WSH-wrapped P2TR 地址的支持？ 除了 BIP341 提及的碰撞安全问题外，jnewbery 还指出多出一种输出类型会带来的隐私问题，以及当前广泛采用 bech32 后，wrapped taproot 输出是否确有需要仍然值得商榷。

准备 taproot #2：对于单签名来说 taproot 真的值得吗？

每周一篇的系列文章，讲述开发者和服务提供商如何为即将到来的、在区块高度 709,632 处激活的 taproot 做好准备。

使用 Optech 的 交易大小计算器，我们可以比较不同类型单签名交易的大小。正如预期，使用 P2WPKH 输入和输出的交易远小于使用 P2PKH 输入和输出的交易——但或许令人惊讶的是，P2TR 交易比同等的 P2WPKH 交易略大。

	P2PKH (legacy)	P2WPKH (segwit v0)	P2TR (taproot/segwit v1)
Output	34	31	43
Input	148	68	57.5
2-in, 2-out tx	374	208.5	211.5

这可能会让人觉得，为了迎接在区块 709,632 激活的 taproot 而在单签名钱包中实现 taproot 花费是得不偿失的，但当我们进一步研究时会发现，对于钱包用户和整个网络而言，使用 P2TR 进行单签名仍然有许多好处。

• ● 花费更便宜： 与花费 P2WPKH UTXO 相比，花费单签名 P2TR UTXO 在输入层面上节约了大约 15% 的成本。上表这样过于简单的分析掩盖了一个细节，即花费者无法选择他们被要求支付的地址，所以如果你还停留在 P2WPKH，而其他人都升级到了 P2TR，那么你的 2 入、2 出交易的实际常见大小将会达到 232.5 vbytes——而全部使用 P2TR 的交易仍然只有 211.5 vbytes。

• ● 隐私： 虽然当早期采用者切换到新的脚本格式时会失去一些隐私，但用户切换到 taproot 也能立刻获得隐私增强。你的交易在链上可能与正在使用新 LN 通道、更高效的 DLCs、安全的多签、各种巧妙的钱包备份恢复方案或其他上百种全新发展场景的人看起来毫无区别。

  现在就对单签名采用 P2TR 还能让你的钱包在之后升级到多签名、tapscript、LN 支持或其他功能时，不会影响你的现有用户的隐私。UTXO 是在你旧版或新版软件中接收的都无关紧要——这两种 UTXO 在链上看起来没有差别。

• ● 更方便硬件签名设备： 自从重新发现了手续费超额支付攻击以来，一些硬件签名设备在没有为该交易输入的每个 UTXO 提供元数据（包含创建该 UTXO 的完整交易中重要部分的副本）的情况下，拒绝为交易签名。这样会极大增加硬件签名器需要执行的最糟糕情况处理量，对主要通过尺寸有限的二维码进行交互的硬件签名器来说尤其棘手。taproot 消除了导致手续费超额支付攻击的漏洞，从而能够显著提高硬件签名器的性能。

• ● 更可预测的费率： 适用于 P2PKH 和 P2WPKH UTXO 的 ECDSA 签名大小具有灵活性（参见 Newsletter #3）。由于钱包需要在创建签名前先决定交易的费率，大多数钱包只是默认假设最糟糕的签名大小，并接受在实际生成更小签名时稍微超额支付费率。对于 P2TR，则可以预先明确签名的确切大小，钱包就能可靠地选择精准的费率。

• ● 帮助全节点： 比特币系统的整体安全性依赖于有相当比例的比特币用户使用自己的节点验证所有已确认的交易，包括验证你的钱包所创建的交易。taproot 的 schnorr 签名可以被高效地批量验证，在节点赶上之前区块的过程中，CPU 耗时大约可以减少一半。即使你对上面提到的其他优势都不感兴趣，也可以考虑为了那些运行全节点的人而做好使用 taproot 的准备。

值得注意的代码和文档更改

本周在 Bitcoin Core、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、比特币改进提案（BIPs）和闪电网络规范（BOLTs） 中的部分值得注意的更改。

• ● Bitcoin Core #22154 为 taproot 激活后生成 P2TR 脚本的 bech32m 地址添加了支持，例如可以通过调用 getnewaddress "" bech32m 来实现。如果在 taproot 激活后，交易包含任何 bech32m 地址，那么描述符钱包也会使用一个 P2TR 的找零输出。该功能仅适用于带有 taproot 描述符的钱包（参见 Newsletter #152）。

• ● Bitcoin Core #22166 增加了从输出中推断 taproot tr() 描述符的支持，从而完成了对基本 taproot 描述符的支持。描述符推断被用于在调用 listunspent 等 RPC 时，提供更精确的返回信息。

• ● Bitcoin Core #20966 更改了保存封禁列表文件的名称和格式，将原来的 banlist.dat（基于 P2P 协议序列化的 addr 消息）更改为 banlist.json。文件格式的更新允许新列表存储 Tor v3 以及其他网络上超过 128 比特宽度地址的节点封禁条目——旧的 addr 消息只能包含最多 128 比特宽度的地址。

• ● Bitcoin Core #21056 为 bitcoin-cli 新增了一个 -rpcwaittimeout 参数。现有的 -rpcwait 参数可以在 bitcoind 服务启动前延迟发送命令（RPC 调用），而新参数允许在指定秒数后停止等待并返回错误。

• ● C-Lightning #4606 允许创建金额超过约 0.043 BTC 的发票，这与 LND 的类似改动（参见 Newsletter #93）以及下一个项目中描述的规格更改相呼应。

• ● BOLTs #877 移除了协议层面原本针对每笔付款金额的限制，该限制最初是为防止实现上的漏洞导致重大损失而引入的。随着 2020 年引入 option_support_large_channel（在启用时移除了每条通道的金额限制），对大额通道的进一步支持使得去除这条限制成为可能。有关这两种限制的更多细节可参见大额通道。