本周的 Newsletter 总结了关于提议的 taproot 激活方法的持续讨论，并链接到一个记录现有基于 taproot 的软件构建工作的尝试。还包括我们定期的部分内容，涵盖了 Bitcoin Core PR 审查俱乐部会议的总结、新的发布与候选发布的公告，以及对流行比特币基础设施项目的值得注意更改的描述。

新闻

  • ● Taproot 激活讨论： 前几周的讨论中，不同群体分别反对 BIP8 LockinOnTimeout=true (LOT=true) 或 LOT=false。因此，本周邮件列表上的大部分讨论集中在其他激活机制上。一些提议包括：

    • ● 用户激活软分叉（UASF）： 正在讨论的计划是在一个 Bitcoin Core 的软件分叉中实施 BIP8 LOT=true，要求矿工在 2022 年 7 月（如广泛提议的）之前为 taproot 激活进行信号，但也允许矿工更早地激活。

    • ● 特定区块高度（flag day）： 几个提案（1、2）主张在大约 18 个月后（如提议）在节点中编程一个特定区块高度或时间点来激活 taproot。矿工信号并非激活所必须，也无法导致更早的激活。Anthony Towns 编写了一个草案实现。

    • ● 阈值逐渐递减： 几个提案（1、2）主张随着时间的推移逐渐减少在新共识规则锁定之前需要矿工为 taproot 执行进行信号的区块数量。另请参见 Anthony Towns 去年在 Newsletter #107 中描述的提案。

    • ● 可配置的 LOT： 除了先前讨论过的将 BIP8 的 LOT 值作为配置选项的提议（见 Newsletter #137），还发布了演示如何通过调用 RPC 命令的外部脚本来强制执行 LOT=true 的初步代码。此外，还创建了代码展示节点运营者如何在担心 LOT=true 会造成区块链不稳定的情况下反对它。

    • ● 短期矿工激活尝试： 更新的提案给矿工大约三个月的时间来锁定 taproot，从实现激活逻辑的全节点发布后不久开始计时。如果尝试失败，社区将被鼓励转向其他激活方法。如果尝试成功，仍将有数月的延迟期以便大多数经济体升级他们的节点。该提案的草案实现有基于 Bitcoin Core 现有 BIP9 代码的版本和基于之前提议的 BIP8 实现的版本，分别由 Anthony Towns 和 Andrew Chow 编写。

    尽管似乎没有任何提案会成为几乎所有人的首选，但看起来有许多人愿意接受在“Speedy Trial”名义下的短期尝试方法。对此仍有一些顾虑，包括：

    • ● 可能被强制激活所利用： 尽管该提案明确鼓励在矿工未能快速足够地信号支持 taproot 时使用其他激活尝试，但有担忧这可能被某些用户群体利用来快速强制激活，尽管有人指出此前没有群体曾表示想在如此危险的短时间内尝试强制激活。

    • ● 使用基于时间还是区块高度的参数： 该提案描述了使用时间戳（基于前 11 个区块的中值时间）还是区块高度来设置 start、timeout 和 minimum_activation 参数的权衡。使用时间戳将产生最小且最易审查的对 Bitcoin Core 的补丁。使用高度则提供更多可预测性，尤其对矿工而言，并与使用 BIP8 的其他尝试兼容。

    • ● 短视（myopic）： 有担忧认为该提案过于关注短期。正如在 IRC 中总结的：“Speedy Trial 为（矿工激活 taproot 的）可能情况做好了充分准备，但并未将 Segwit 激活不及时的经验教训进行制度化。我们有机会在 taproot 激活中为未来的激活创建一个模板，明确开发者、矿工、商家、投资者和最终用户在各种激活路径下的角色与责任，尤其是在启用和确立比特币经济用户作为最终仲裁者的角色上。如果现在不定义，将来只会更困难，因为我们只有在危机中才会去做，并且随着比特币的增长，将来达成共识将需要在更大规模上进行，更加困难。”

    • ● 速度（Speed）： 基于对 ##taproot-activation IRC 频道的初步讨论，该提案建议给矿工约三个月的时间来锁定 taproot，并从开始度量信号的时间点起等待固定的六个月（如果锁定成功）再激活。一些人希望时间稍短或稍长。

    我们将继续跟踪各种提案的讨论，并在未来的 Newsletter 中总结任何重要进展。

  • ● 记录使用与构建在 taproot 之上的软件意愿： 在关于激活方法的讨论中，Chris Belcher 指出，在为 Segwit 激活进行辩论期间，人们曾收集过一个大型列表，列出表示打算实现 Segwit 的软件开发者。他建议可以创建一个类似的列表来记录对 taproot 的支持程度，从而表明无论 taproot 最终如何被激活，它都是被大量经济参与者所期望的。

    Jeremy Rubin 在 Bitcoin-Dev 邮件列表发帖链接了一个相关的wiki 页面，开发者可以在上面发布其基于 taproot 的新功能构建的项目链接。这可为 taproot 确保提供实际需求的解决方案，并表明其特性设计是会被实际使用的。

Bitcoin Core PR 审查俱乐部

在本月度部分中，我们总结了最近的 Bitcoin Core PR 审查俱乐部会议，突出一些重要的问题和答案。点击下面的问题可查看会议中答案的摘要。

Erlay：带宽高效的交易中继协议是 Gleb Naumenko 的一个 PR（#18261），提议在 Bitcoin Core 中实现 BIP330。

审查俱乐部讨论集中在采用 Erlay 所涉及的权衡、实现和潜在的新攻击向量上。在后续的会议中，审查俱乐部讨论了 Minisketch，这是一个实现 PinSketch “集合同步（set reconciliation）”算法的库，是 Erlay 中高效中继协议的基础。

  • 什么是 Erlay？

    一种基于泛洪与集合对账相结合的新型交易中继方法（当前的交易中继仅依赖泛洪），可提高带宽效率、可扩展性和网络安全性。该理念在 2019 年的论文 Bandwidth-Efficient Transaction Relay for Bitcoin 中提出，并在 比特币改进提案（BIPs）330 中进行了规范。 

  • Erlay 带来哪些优势？

    交易中继的带宽使用量降低，约占节点运行所需带宽的一半；以及 节点连接数量的可扩展性，从而使网络对分区攻击更具韧性，并使 单个节点更能抵御 Eclipse 攻击。 

  • Erlay 的一些权衡点是什么？

    交易传播延迟的边际增加。据估计，Erlay 会将未确认交易在所有节点间中继的时间从约 3.15 秒增至约 5.75 秒，但这相比整体约 10 分钟的交易处理时间仅是很小的一部分。另一个权衡点是额外的代码与计算复杂度。 ➚

  • 为何 Erlay 引入的集合对账比泛洪更易扩展？

    通过泛洪进行的交易传播中，每个节点都会向其所有对等节点通告其收到的每笔交易，这导致带宽效率低下且冗余度高。当网络连接性提升后，此问题会愈加明显，而改善网络连接本应有利于网络的增长与安全性。Erlay 通过减少低效泛洪发送的交易数据，并以更高效的集合对账方式替代，从而提高可扩展性。 

  • 对现有点对点消息类型的发送频率会有何变化？

    在 Erlay 中，inv 消息的发送频率将降低；getdata 和 tx 消息的发送频率不变。 ➚

  • 两个节点将如何就使用 Erlay 的集合对账功能达成一致？

    通过在 version-verack 握手阶段交换一个新的 sendrecon 点对点消息来实现。 ➚

发布与候选发布

流行比特币基础设施项目的新发布和候选发布。请考虑升级到新版本或帮助测试候选发布。

  • ● Eclair 0.5.1 是该闪电网络节点的最新版本，包含了启动速度的提升、在同步网络图时降低带宽消耗，以及为支持锚定输出做准备的一系列小改进。

  • ● HWI 2.0.0RC2 是 HWI 下一个主要版本的发布候选版本。

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

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