本周的周报介绍了 Bitcoin-Dev 邮件组的一项即将到来的变更，并简要总结了一项允许聚合多个 HTLC 的提议。此外是我们的常规栏目：Bitcoin Core RP 审核俱乐部会议的总结、软件的新版本和候选版本的公告，以及热门比特币基础设施软件的重大变更的介绍。

新闻

  • ● 邮件组的托管：Bitcoin-Dev 邮件组的管理员宣布，当前托管邮件组的组织计划在今年结束之后不再托管任何邮件组。在可以预见的时间内，以往的邮件的档案预计会几乎托管在当前的 URL。我们估计邮件转发服务的终止也会影响 Lightning-Dev 邮件组，因为它们也是由同一个组织托管的。

    管理员征求社区的反馈，包括是否接受将邮件组迁移到 Google Groups。如果迁移发生，Optech 将开始使用那个群组作为我们的新闻信息源之一。

    我们也注意到，早在这次公告的几个月之前，一些有名的开发者已经开始尝试在 DelvingBitcoin 网上论坛讨论事情。Optech 将立即开始观察这个论坛上的有趣和重要的讨论。

  • ● 使用限制条款聚合 HTLC：Johan Torås Halseth 在 Lightning-Dev 邮件组中提出了一项使用一种 “限制条款（covenant）” 来聚合多个 HTLCs 成一个输出的提议；如果一方知道所有的原像，这样的输出就可以一次性花费掉。如果一方只知道一部分原像，TA 就只能取走相应的那部分资金，剩余的资金将由另一方收回。Halseth 指出，这种构造的链上效率更高，而且更能抵御某些类型的 “%#%”。

Bitcoin Core PR 审核俱乐部

在这个月度栏目中，我们会总结最近一期 Bitcoin Core PR 审核俱乐部会议，列出一些重要的问题和回答。点击下文的问题描述，便可看到会上讨论出的答案。

“从 Validation Interface/CScheduler 线程更新手续费估算器” 是一项由 Abubakar Sadiq Ismail (ismaelsadeeq) 提出的 PR，修改了交易手续费估算器的数据更新方式。（当一个节点的主人要发起一笔交易的时候，就会使用手续费估算。）它将手续费估算在交易池更新（添加或移除交易）时同步更新改成了异步更新。虽然这在整体上加入了更多的处理复杂性，但它提升了关键路径的性能（下文的讨论会证明这一点）。

在发现一个新区块时，交易池内的任何交易，无论与区块所包含的交易重复还是冲突，都会从交易池中移除。因为区块处理和转发是性能关键型（performance-critical）任务，减少处理一个新区块所需的工作量（比如更新手续费估算器）是很有好处的。

  • 移除 CTxMempool 对 CBlockPolicyEstimator 的依赖有什么好处？

    当前，在收到一个新区块时，CTxMempool 的处理会被阻断，同时更新手续费估算器。这会拖慢新区块的处理，因此也会拖延区块的转发。移除 CTxMempool 对 CBlockPolicyEstimator 的依赖将允许手续费估算异步（在另一个线程中）更新，从而区块验证和转发都可以更快地完成。这项更新也让 CTxMempool 的测试变得更加容易。最后，它还允许在未来引入更加复杂的手续费估计算法，而无需担心影响区块验证和转发的性能。 ➚

  • 现在的手续费估算更新跟交易池添加或移除交易（即使没有新区块到达）不是同步的吗？

    是同步的，但这时候的性能没有在区块验证和转发的时候那么重要。 ➚

  • CBlockPolicyEstimator 称为 CTxMempool 的一个成员并同步地更新（即当前的安排）有什么好处的吗？移除它又会有什么坏处？

    同步模式的代码会更加简单，也更易于分析。此外，手续费估算器也对整个交易池了解更充分；一个缺点是需要将手续费估算器所需的所有信息都封装到一个新的 NewMempoolTransactionInfo 结构中。不过，手续费估算器并不需要太多信息。 ➚

  • 你认为这项 PR 所采取的方法，与 PR 11775 所采取的分拆 CValidationInterface 的方法相比，有何 优点/缺点？

    虽然分拆它们似乎很棒，但它们依然有共享的后端（以保证事件的排序良好），所以也做不到非常独立。所以分拆似乎并没有很多实际上的好处。当前这个 PR 更加聚焦，而且尽可能小范围地让手续费估算异步更新。 ➚

  • 在一个子类中，为什么实现一种 CValidationInterface 等价于订阅这个事件？

    CValidationInterface 的所有子类都是客户端。这些子类可以实现一些或全部的 CValidationInterface 方法（回调），举个例子，连接或断开一个区块、连接一个加入交易池的交易或断开一个从交易池中驱逐的交易。在（通过调用 RegisterSharedValidationInterface()）注册之后，任何实现了 CValidationInterface 的方法都会在使用 CMainSignals 触发这种方法的回调时执行。而每次相应事件发生时，都会触发回调。 ➚

  • BlockConnected 和 NewPoWValidBlock 是不同的回调。哪一种是异步的、哪一种是同步的？你是怎么辨别的？

    BlockConnected 是异步的； NewPoWValidBlock 是同步的。异步的回调会形成一个 “事件”并排队，等待在 CScheduler 线程中执行。 ➚

  • 为什么我们要在 commit 4986edb 中增加一种新的回调 MempoolTransactionsRemovedForConnectedBlock，而不是使用 BlockConnected 呢（后者也会暗示一笔交易正从交易池中移除）？

    手续费估算器需要在任何交易从交易池中移除时知晓（不论出于什么理由），而不能仅仅是在连接着一个区块时才能知晓。此外，手续费估算器还需要一笔交易的基本手续费（base fee），而 BlockConneted 是无法提供的（它只能提供一个 CBlock）。我们可以将基本手续费添加到 block.vtx（交易列表）条目中，但仅仅是为了支持手续费估算就改变这样一个重要而且无处不在的数据结构，是不可取的。 ➚

  • 为什么不使用 std::vector<CTxMempoolEntry> 作为 MempoolTransactionsRemovedForBlock 回调的一个参数？这就不需要一种新的结构体类型来保存手续费估算所需的每一笔交易的信息了。

    手续费估算不需要来自 CTxMempoolEntry 的所有字段。 ➚

  • 一个 CTransactionRef 的基本手续费是如何计算的？

    所有输入的价值的和减去所有输出的价值的和。但是，回调无法读取输入的价值，因为这是存储在前序交易的输出中的。这就是 TransactionInfo 结构体要包含基本手续费的原因。 ➚

新版本和候选版本

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

重大的代码和文档变更

本周出现重大变更的有：Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals (BIPs)、Lightning BOLTs 和 Bitcoin Inquisition。

  • ● Core Lightning #6824 更新了 “交互式注资协议” 的实现，以 “在发送 commitment_signed 时存储状态，并给 chennel_reestablish【添加】一个 next_funding_txid 字段，以向对等节点请求重新发送己方没有收到的签名。”本更新基于拟议的 “双向注资 PR” 的一个更新。

  • ● Core Lightning #6783 弃用了 large-channels 配置选项，让大容量通道和大额支付总是启用。

  • ● Core Lightning #6780 提升了对使用 “锚点输出（anchor outputs）” 的链上交易手续费追加手段的支持。

  • ● Core Lightning #6773 允许 decode RPC 验证一个备份文件的内容是有效的、并包含了执行一次完整的复原所需的最新信息。

  • ● Core Lightning #6734 更新了 listfunds RPC，以在用户想要运用 “子为父偿（CPFP）” 为合作关闭交易追加手续费时提供所需的信息。

  • ● Eclair #2761 允许转发有限数量的 HTLCs 给对方，即使对方的余额已低于通道保证金的要求。这可以帮助解决 “通道拼接（splicing）” 或者双向注资之后可能发生的 资金滞留问题（suck funds problem）。见周报 #253 了解 Eclair 为资金滞留问题提出的另一项缓解措施。

想要了解更多？

想要了解更多本周新闻部分提到的话题的讨论，请加入我们于每周四（周报发布的后一天）的 UTC 时间 15:00 在 Twitter Spaces 举办的 Bitcoin Optech 回顾。聊天室里的讨论也会记录在我们的播客页面并长期留存。