本周的 Newsletter 庆祝了 taproot 软分叉的锁定，介绍了一份通过改变实现防止 fee sniping 时所使用字段来改善交易隐私的 BIP 草案，并讨论了在结合交易替换（RBF）和批量支付时可能遇到的挑战。此外，我们也照例带来了新软件版本与候选发布的公告，以及常用比特币基础设施软件中的值得注意的更新内容。

新闻

• ● 🟩 Taproot 已锁定： taproot 软分叉及其在 BIPs 340、341、342 中所指定的相关更改已在上周末由发送信号的矿工锁定。taproot 预计将在区块高度 709,632（大约在 11 月上旬或中旬）之后安全可用。这段延迟使用户有时间升级他们的节点至会强制执行 taproot 规则的发行版本（如 Bitcoin Core 0.21.1 或更高版本），从而确保在区块高度 709,632 之后接收至 taproot 脚本的资金即便在出现矿工问题时也能获得安全保障。

  我们鼓励开发者开始实现 taproot，以便在激活完成后立即利用其更高的效率、隐私和可替代性。

  正在庆祝 taproot 锁定的读者也可以阅读开发者 Pieter Wuille 的一段简短推文，了解有关 taproot 起源和历史的介绍。

• ● 提议为钱包在 taproot 交易中默认设置 nSequence： Chris Belcher 在 Bitcoin-Dev 邮件列表提交了一份 BIP 草案，建议使用一种可替代方式来实现防止 fee sniping。该替代方案能增强单签用户、multisignature 用户，以及某些使用 taproot 功能的合约协议用户（例如闪电网络或高级 coinswaps）所进行交易的隐私和可替代性。

  防止 fee sniping 是一些钱包为阻止矿工相互窃取费用而采用的技术，这种相互窃取费用的行为会降低保护 Bitcoin 的工作量证明总量，并削弱用户对确认次数的依赖能力。当前所有实现了防止 fee sniping 的钱包都使用 nLockTime 的区块高度锁定，但也可以通过 BIP68 的 nSequence 区块高度锁定实现同样的保护功能。这样做并不会更有效地防止 fee sniping，但它会鼓励普通钱包将其 nSequence 值设置为某些基于多签的合约协议（如 coinswaps 或使用 taproot 的闪电网络）所需的相同数值，从而让普通钱包的交易看起来与这些协议的交易类似，反之亦然。

  Belcher 的提案建议钱包在两种方式都可用时，以 50% 的概率随机选择 nLockTime 或 nSequence。总体而言，如果这一提案被采纳，对于使用常规单签或多签交易的用户以及各种合约协议用户，双方都可通过这种做法共同提升彼此的隐私与可替代性。

实地报告: 使用 RBF 和批量添加

“批量添加”是一种在内存池中将额外输出添加到未确认交易的方案。本文汇报了 CardCoins 在其客户提现流程中引入该方案的再组织（reorg）与 DoS 安全实现所做出的努力。

Replace By Fee（RBF，BIP125）与批量支付是与比特币内存池直接交互的企业不可或缺的两种工具。无论手续费上涨还是下跌，企业始终需要在手续费效率方面不断努力。

每种工具都十分强大，但也各有复杂性与细微之处。例如，为客户提现进行批量支付可能能为企业节省手续费，但也会让需要加速交易的客户通过 CPFP 的方式变得不划算。同样，RBF 对于采用“低费率初始广播、逐步提高费率”策略的企业很有用，但它会让客户在看到自己的提现交易在钱包里更新时可能产生混淆。此外，如果客户想在此交易依然未确认的情况下花费它，那么企业在尝试替换其父交易时就必须承担这笔子交易的费用。更糟糕的是，客户在另一个服务那里收到的这笔提现交易可能被对方固定。

将这两种工具结合使用时，服务提供商会获得新功能，但也会面临新的复杂性。在最基本的场景下，将 RBF 与单一、固定的批量支付结合，其复杂性仅是二者分别存在的复杂性的简单叠加。然而，当你把 RBF 与“additive batching” 组合时，就会出现某些边缘案例与危险的故障情形。

在 “additive RBF batching” 场景下，服务提供商会在交易仍处于内存池且尚未确认时，引入新的输出（以及已确认的输入），从而把新的客户提现纳入这笔交易。这使得服务提供商能为用户带来近乎即时提现的体验，同时保留通过批量处理大量客户提现所带来的大部分手续费节省。当每位客户请求提现时，就会向内存池中的交易添加一个输出。直到该交易被确认或到达其他本地最优状态前，它都会继续被更新。

针对这种 “additive RBF batching”，可能存在多种策略。在 CardCoins，我们采用了安全优先的方式实现（并得到了 Matthew Zipkin 的协助），并在博客文章 RBF Batching at CardCoins: Diving into the Mempool’s Dark Reorg Forest 中对此实现细节进行了介绍。

发布与候选发布

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

• ● Rust Bitcoin 0.26.2 这是该项目最新的小版本更新。与上一个主要版本相比，其中包含若干 API 改进与错误修复，详情可参阅 changelog。

• ● Rust-Lightning 0.0.98 小版本更新，包含若干改进与错误修复。

• ● LND 0.13.0-beta.rc5 这是一个候选发布版本，增加了对修剪过的比特币全节点的支持，允许使用原子多路径支付（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 GUI #4 为通过 GUI 使用 Hardware Wallet Interface (HWI) 外部签名器提供了初步支持。在该功能完善后，用户将能够直接在 Bitcoin Core GUI 中使用其兼容 HWI 的硬件钱包。

  

• ● Bitcoin Core #21573 更新了 Bitcoin Core 中使用的 libsecp256k1 版本。其中最值得注意的更改是引入了之前在 Newsletter #136 和 #146 中提到的优化模逆代码。根据该拉取请求中公布的性能评估数据，这项更新为旧区块验证带来了约 10% 的速度提升。

• ● C-Lightning #4591 添加了对解析 bech32m 地址的支持。当节点协商启用 option_shutdown_anysegwit 功能后，C-Lightning 现在允许指定任意 v1+ 的原生 segwit 地址作为关闭通道或提现操作时的目标地址。