本周的周报总结了邮件列表中关于使用 MATT 提案来管理 joinpools 和OP_CHECKTEMPLATEVERIFY 提案复制功能的讨论。此外，还包括我们关于交易池策略的限定版周刊系列的另一篇文章，以及我们常规发布新软件版本和发布候选版本，并描述了流行的比特币基础设施软件的重要变更。

News

• ● 使用 MATT 复制 CTV 和管理 joinpools： Johan Torås Halseth 在 Bitcoin-Dev 邮件列表中发布了如何使用 Merklize All The Things (MATT) 提案（参见周报#226 和#249）中的 OP_CHECKOUTPUTCONTRACTVERIFY 操作码（COCV）来复刻 OP_CHECKTEMPLATEVERIFY 提案中的功能。为了提交具有多个输出的交易，每个输出都需要使用不同的 COCV 操作码。相比之下，单个 CTV 操作码可以提交给所有输出。这使得 COCV 效率较低，但正如他指出的那样，“简单到有趣”。

  除了描述功能，Halseth 还提供了使用 Tapsim（一种用于“调试比特币 Tapscript 交易 […] 针对希望与比特币脚本原语进行交互、帮助脚本调试并可视化脚本执行时的虚拟机状态的工具”）的操作演示。

  在另一个帖子中，Halseth 发布了关于使用 MATT 加上 OP_CAT 创建 joinpool（也称为_coinpool_ 或 payment pool）的内容。同样，他提供了一个使用 Tapsim 的交互式演示。基于实验性实现的结果，他也提供了几个对 MATT 提案中操作码的修改建议。MATT 提案的发起人 Salvatore Ingala 对此进行了积极地回复。

等待确认 #4：费率估算

这是一个关于交易转发、交易池纳入以及挖矿选择的限定周刊系列 —— 解释了为什么 Bitcoin Core 设置了比共识规则更严格的交易池规则，以及钱包可以如何更高效地使用这些交易池规则。

上周，我们探讨了在给定费率的情况下，最小化交易手续费的技巧。但是，费率应该是多少呢？理想情况下，它应该尽可能低（为了省钱），同时又高到足以保证交易在适合用户时间偏好的区块中获得一个位置。

费（率）估算 的目标是将确认的目标时间转化为交易应支付的最低费率。

费率估算的一个复杂之处在于区块空间生产的不规律。假设一个用户需要在一小时内支付给商家，以收到商品。用户可能期望每 10 分钟挖出一个区块，因此目标是在接下来的 6 个区块中找到一个位置。然而，完全有可能一个区块需要 45 分钟才能被挖出。费率估算器必须在用户期望的紧急程度或者时间窗口（类似于“我希望在工作日结束之前确认这笔交易”）和区块空间供应（一定数量的区块）之间进行转换。许多费用估算器通过将确认目标以区块数量和时间的形式表示来解决这个挑战。

如果没有正在等待确认的交易的信息，人们可以依据历史数据（已经入块的交易的费率）构建一个简单的费用估算器。由于这样的估算器没有考虑交易池中待确认的交易，在区块空间需求出现意外波动和偶尔的长区块间隔时，它会变得非常不准确。它的另一个弱点是它完全依赖矿工控制的信息，矿工可以通过在他们的区块中包含虚假的高费率交易来推高（估算）费率。

幸运的是，区块空间的市场并不是暗标拍卖。我们在第一篇文章中提到，保留交易池并参与点对点交易中继网络允许节点查看用户的出价。Bitcoin Core 费用估算器还使用历史数据来计算交易在 n 个区块内以费率 f 确认的可能性，但具体跟踪节点首次看到交易的高度以及交易确认的时间。这种方法通过忽略公开费用市场之外发生的活动来避免被它们影响。如果矿工在自己的区块中人为地包含高费率交易，则该费用估算器不会出现偏差，因为它仅使用在确认之前被公开转发的交易的数据。

我们还深入了解了为区块选择交易的方式。在上一篇文章中，我们提到节点模拟矿工策略，以便在其交易池中保留激励兼容的交易。扩展这个想法，我们可以构建一个费用估算器来模拟矿工会做什么，而不只是查看过去的数据。为了找出交易在接下来的 n 个区块中为确认所需要的费率，费用估算器可以使用区块组装算法从其交易池中预测接下来的 n 个区块模板，并计算出击败费率最低一笔交易、从而可以进入到区块 n 中的费率。

显然，该费用估算器方法的有效性取决于其交易池内容与矿工内容之间的相似性，而这一点永远无法得到保证。它还忽视了矿工由于外部动机而可能包含的交易，例如，矿工自己的交易、在系统外给矿工支付费用的交易。预测还必须考虑从现在到预测区块被挖出之间新出现的交易。可以通过减少预计区块的大小，来容纳其它交易所带来的影响——但减少多少呢？

这个问题再次凸显了历史数据的效用。智能模型可能能够整合活动模式并考虑影响费率的外部事件，例如典型的营业时间、公司定期的 UTXO 合并以及针对比特币交易价格变化的活动。预测区块空间需求的问题仍然有待探索，并且可能永远有创新的空间。

费用估计是一个多方面且困难的问题。糟糕的费用估计可能会超付费用（也即浪费资金）、增加比特币在支付方面的摩擦、导致 L2 用户因错过一个时间锁定的 UTXO 的备用花费路径而损失资金。良好的费用估计可以让用户清楚而准确地向矿工传达交易的紧急程度，而 CPFP 和 RBF 允许用户在初始估计不足时更新出价。激励兼容的交易池策略，与良好设计的费用估计工具和钱包相结合，使用户能够参与高效的公共拍卖以获取区块空间。

费用估算器通常不会返回低于 1sat/vB 的任何值，无论时间范围有多长，待确认的交易有多少。许多人认为 1sat/vB 是事实上的最低费率。这是因为在比特币网络中，网络上的大多数节点（包括矿工）从不接受低于该费率的任何交易，无论他们的交易池有多空。下周的文章将探讨这种节点策略以及利用费率在交易中继中的另一个动机：防止资源耗尽。

发布和发布候选版本

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

• ● LND 0.16.3-beta 是这个流行的闪电网络节点实现的维护版本。其发布说明称，“此版本仅包含错误修复，旨在优化最近添加的交易池监视逻辑，并修复了几个疑似的意外强制关闭向量”。有关交易池监视逻辑的更多信息，请参见周报 #248。

重大的代码和文档变更

本周出现重大变更的有：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。

• ● Bitcoin Core #26485 允许接受 options 对象参数的 RPC 方法接受与命名参数相同的字段。例如，现在可以使用 src/bitcoin-cli -named bumpfee txid fee_rate=10 调用 bumpfee RPC，而不是 src/bitcoin-cli -named bumpfee txid options。

• ● Eclair #2642 添加了一个closedchannels RPC，提供有关节点关闭的通道的数据。还可以参考 Core Lightning 中类似的 PR，详见周报 #245。

• ● LND #7645 确保 RPC 调用中的任何用户提供的费率在 OpenChannel、CloseChannel、SendCoins 和 SendMany 中不低于“中继费率”。更改注释中“‘中继费率’的含义可能因后端而异。对于 bitcoind 来说，它实际上是 max(relay fee, min mempool fee)”。

• ● LND #7726 将始终花费所有 HTLC 来向本地节点支付，如果需要在链上结算通道。即使结算这些 HTLC 可能会产生比它们的价值更多的交易费用，它也会结算这些 HTLC。与 Eclair 的一个 PR 相比，Eclair 在上周的周报中描述的程序现在不会尝试去索取一个不经济的 HTLC。PR 讨论帖中的评论提到 LND 正在努力实现其他改变，以增强其计算与解决 HTLC 相关的成本和收益的能力（无论是离线还是在线），从而使其能够在未来做出最佳决策。

• ● LDK #2293 如果对等节点没有在合理的时间内回应，则断开连接然后重新连接。这可能会缓解其他闪电网络软件有时会停止响应导致通道被强制关闭的问题。