本周的 Newsletter 介绍了一个允许所有交易进行 RBF（Replace-by-Fee）的提案，并带来了新系列文章“为 taproot 做准备”的首篇。此外，我们也照例介绍了对客户端和服务端的更新、新软件版本与候选发布，以及常用比特币基础设施项目的值得注意的变更内容。

新闻

• ● 允许默认进行交易替换： 目前，大多数比特币全节点都被认为实现了 BIP125 中的选择性 RBF（Replace By Fee），这允许未确认交易在节点的内存池中被其他支付更高手续费的版本所替换——但前提是交易创建者在原始交易中设置了相应信号。最初提出此种选择性机制是因为希望进行交易替换（例如用于手续费提升或批量支付添加）的人，与反对者（因为交易替换会让诈骗使用未确认交易的商家变得更容易）之间存在分歧。

  五年多时间过去后，似乎目前很少商家在将未确认交易视为最终交易，而且尚不清楚这些商家中有多少真的在检查 BIP125 的选择性信号并对其区别对待。如果没人依赖 BIP125 信号，那么默认允许所有交易都可被替换，或许能带来以下好处：

  • ● 简化对预签名交易协议的分析 （例如用于闪电网络和保险库等）——其中，利用 RBF 来提高手续费的设想，必须考虑到恶意对手方可以阻止在原始交易中设置 BIP125 信号。如果任何交易都能被替换，则无需担心这一点。

  • ● 减少交易分析机会 因为开启 RBF 的交易与未开启 RBF 的交易在链上表现不同。目前大多数钱包要么一致地选择开启，要么一致地选择不开启；这种差异为监控公司提供了分辨谁拥有哪些比特币的线索。假如所有交易都可替换，就无需再设置 BIP125 信号了。

  本周，Antoine Riard 在 Bitcoin-Dev 邮件列表发布了一项提案，最终可能让 Bitcoin Core 无视 BIP125 选择性信号来支持所有交易的 RBF 功能。该想法在首次交易中继研讨会会议上也进行了讨论。与会者提及了 Bitcoin Core PR #10823 作为一种替代方案——它允许任何交易被替换，但仅限在交易已在节点内存池中存在一定时长（最初提议 6 小时，后也有人建议 72 小时）之后。

  无论选择哪种方法，当讨论扩大到允许替换未设置 BIP125 信号的交易时，都需要考虑目前依赖 BIP125 行为的商家意见。Optech 也鼓励所有此类商家在邮件列表上发表看法。

对服务和客户端软件的更改

在本月度栏目中，我们聚焦介绍比特币钱包和服务的有趣动态。

• ● Trezor Suite 添加 RBF 支持： Trezor 的钱包软件 Trezor Suite 在 21.2.2 版本中添加了对 RBF 的支持。RBF 默认开启，并已在部分 Trezor 硬件设备中得到支持。

• ● Lightning Labs 宣布 Terminal Web： 在一篇博客中，Lightning Labs 介绍了他们的基于 Web 的闪电网络节点评分仪表盘 Terminal Web。

• ● Specter v1.4.0 发布： Specter v.1.4.0 中增加了一个使用 BIP125 选择性 RBF “取消”交易的功能。

• ● Phoenix 增加 LNURL-pay： ACINQ 的移动钱包 Phoenix 在 v1.4.12 版本中添加了对 LNURL-pay 协议的支持。

• ● JoinMarket v0.8.3 发布： JoinMarket v0.8.3 新增了为找零地址自定义设置的功能，以及与 Electrum 兼容的隔离见证 signmessage 实现。

准备 taproot #1：Bech32m 发送支持

这是一个每周更新的系列的第一篇，讲述开发者和服务提供商如何为预定在区块高度 709,632 激活的 taproot 做准备。

从预计在 11 月到来的区块高度 709,632 开始，比特币用户将能够安全地接收发送到 taproot 地址的付款。考虑到用户对 taproot 的期待，以及钱包开发者有 5 个月的时间来实现对 taproot 的支持，Optech 预计到时会有数个流行的钱包允许用户在第一时间生成 taproot 地址。

这意味着任何会向用户提供的地址发送比特币的钱包或服务，都需要在区块高度 709,632 前支持发送至 taproot 地址，否则可能会让用户感到困惑并失望。Pay to TapRoot（P2TR）地址使用了 bech32m（参见 BIP350），它与 BIP173 用于 segwit v0 P2WPKH 和 P2WSH 地址的 bech32 算法略有不同。bech32m 在校验和函数中使用 0x2bc830a3 常量，而传统 bech32 则使用 0x01。

只需改变这一常量即可为校验 bech32m 校验和提供支持，但在处理现有 P2WPKH 和 P2WSH 地址时仍要使用原始常量。也就是说，代码需要先在不验证校验和的情况下解析地址，判断它是 v0 segwit（bech32）还是 v1+ segwit（bech32m），然后再使用对应的常量来验证校验和。更多示例可参考 bech32#56，它更新了 C、C++、JS 和 Python 的 bech32 参考实现。如果代码已经使用了参考库，可以更新至该仓库的最新版本，但要注意其中部分 API 发生了小幅更改。BIP350 和参考实现提供的测试向量，所有 bech32m 实现都应当进行使用以验证正确性。

虽然在区块高度 709,632 之前向 taproot 地址接收付款并不安全，但向这些地址发送付款对于付款方而言并不会造成任何问题。自 Bitcoin Core 0.19（2019 年 11 月发布）起，Bitcoin Core 就开始支持传播和挖矿包含 taproot 输出的交易。Optech 鼓励各钱包和服务的开发者现在就着手实现对 bech32m taproot 地址付款的支持，而不要等到 taproot 激活后再做准备。

发布与候选发布

适用于常用比特币基础设施项目的新版本与候选发布版本。请考虑升级到新版本，或协助测试候选发布版本。

• ● LND 0.13.0-beta 这是一次主要版本更新，通过将 anchor outputs 设为默认承诺交易格式来改进手续费管理，新增了对修剪过的比特币完整节点的支持，允许使用原子多路径支付（Atomic MultiPath，简称 AMP）进行接收与发送，并进一步提升了 PSBT 功能。此外还包含其他多项改进与错误修复。

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

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

• ● Bitcoin Core #21365 为钱包在花费 taproot 时创建签名提供了支持，包括仅使用 P2TR 公钥的键路径签名，以及使用 tapscript 的脚本路径签名。钱包也可为基于 taproot 的 PSBT 进行签名，但前提是钱包已具备全部键路径或脚本路径所需的信息。与此相关的另一个合并的拉取请求 #22156 仅在 taproot 激活（主网上是区块高度 709,632）后允许导入这些键路径和脚本路径信息；对于已经启用 taproot 的测试网络，则可立即使用该导入功能。

• ● Bitcoin Core #22144 随机化了在消息处理线程中服务各节点的顺序。该线程负责解析和处理来自各节点的 P2P 消息，并向这些节点发送消息。此前，消息处理线程会按照节点连接先后顺序轮流服务各节点。现在，每次循环时为节点分配服务顺序都将是随机的，从而避免了基于固定服务顺序可能导致的潜在安全弱点或可利用之处，同时仍确保每个节点服务频次相同（在每次循环中服务一次）。

• ● Bitcoin Core #21261 简化了将更多网络纳入入站连接保护的流程，随后也将 I2P 列入了受保护网络。多样化保护（常被称作 eviction protection）可使具有特定特征的节点在 Bitcoin Core 剔除高延迟连接时依然保持连接。保留通过匿名网络连接的节点对同时想隐藏网络身份和在常规 IP 之外接收区块的用户而言都非常重要，从而能防范某些日蚀攻击的形式。

• ● Rust Bitcoin #601 为解析 bech32m 地址提供了支持，并强制要求对 v1 及后续版本的原生 segwit 地址使用 bech32m 而非 bech32 进行编码。

• ● BTCPay Server #2450 当用户选择启用热钱包接收付款时，默认会生成具有 payjoin 功能的兼容发票。创建钱包界面上的一个按钮允许用户取消此默认设置。

• ● BTCPay Server #2559 增加了一个独立的界面，引导用户选择如何为其钱包支出交易进行签名。对于热钱包，服务器可直接签名；但若密钥储存在其他地方，该界面会以更直观的图形方式指导用户选择不同的签名方式，例如：输入恢复助记词、使用硬件签名设备，或生成 PSBT 文件以在可签名的钱包中进行操作。