本周的新闻部分总结了致密区块中继预填充的测试结果，并链接到了一个基于交易池的手续费估算代码库。此外是我们的常规栏目：总结关于比特币共识规则变更的讨论、软件新版本和测试版本的发行公告，以及流行的比特币基础设施软件的变更介绍。

新闻

  • ● 致密区块预填充测试：David Gumberg 在 Delving Bitcoin 论坛的一个关于 “致密区块（compact block）” 重构效率的帖子（周报 #315 和 #339 曾介绍）中回复了他从致密区块中继 预填充 测试中得到的结果 —— 预填充指的是，当一个节点认为其对等节点可能还不知晓下一个区块将包含的交易时，就抢先把这些交易转发给他们。Gumberg 的帖子非常详细，并且链接了一个 Jupyter 笔记，所以其他人也能自己做实验。要点包括：

    • 在不考虑网络流量时，一个确定要预填充什么交易的简单规则可以将区块重新构造的成功率从 62% 提高到大约 98% 。

    • 在考虑网络流量时，一些预填充可能会导致额外的通信轮次 —— 这就打消了所有的好处，而且可能会稍微削弱性能。不过，可以通过构造许多预填充来避免这个问题，从而将重新构造的成功率提高到 93%，并且还可以进一步提升。

  • ● 基于交易池的手续费估计器代码库：Lauren Shareshian 在 Delving Bitcoin 论坛中发帖宣布了一个由 Block 开发的手续费估算器代码库。与别的一些手续费估计工具不同的是，该代码库只使用进入一个节点的交易池的交易流作为估计的基础。帖子比较了该库（Augur）和多个手续费估计服务，发现 Augur 的失手概率较低（即，超过 85% 的交易在其预计的时间窗口内确认），而且平均高估概率也较低（即，平均来说，交易只比必要水平多付了 16%）。

    Abrbakar Sadiq Ismail 回复了这个帖子，并且在 Augur 代码库中打开了一个信息沟通 issue，用于检验该库所用的部分假设。

共识变更

这个月度栏目会总结关于变更比特币共识规则的提议和讨论。

  • ● 从量子脆弱的输出迁移：Jameson Lopp 在 Bitcoin-Dev 邮件组中发帖，提出了一个分成三个步骤、逐渐取消量子脆弱输出的提议。

    • 在 BIP360 量子抗性签名方案（或替代性方案）激活共识的三年之后，激活一个软分叉，从此拒绝支付到量子脆弱地址的交易。只能支付给量子抗性输出。

    • 再过两年，激活第二个软分叉，拒绝从量子敏感地址花费的交易。任何留在量子脆弱输出中的资金，从此都将不可再花费。

    • 可选，在不确定的未来，再激活一次共识变更，允许量子脆弱输出中的资金使用一种量子抗性证据方案来花费（周报 #361 提出了一个例子）。

    该帖子的大部分内容是重复此前关于何以在量子计算机足够快之前就必须阻止人们从量子敏感的输出中花费的讨论（详见 周报 #348）。双方都提出了合理的论证，我们希望辩论能够继续。

  • ● Taproot 原生的 OP_TEMPLATEHASH 提议：Greg Sanders 在 Bitcoin-Dev 邮件组中发布了一个向 tapscript 添加三个操作码的提议。其中两个是此前已被提议的 OP_CHECKSIGFROMSTACK 和 OP_INTERNALKEY（详见 周报 #285）。最后一个是 OP_TEMPLATEHASH，是 OP_CHECKTEMPLATEVERIFY 的 Taproot 原生变种；作者指出原版与变种有以下区别：

    • 不改动传统（隔离见证前）脚本。此前关于这一抉择的讨论见周报 #361。

    • 被哈希的数据（以及哈希的顺序）非常类似于为在 taproot 承诺的签名而哈希的数据，简化了任何已经支持 taproot 的软件的实现。

    • 它会承诺 taproot 附言（annex），而 OP_CTV 不会。它的一种用法是，可以用来保证一些数据会作为交易的一部分，比如用在合约式协议中、允许对手方从旧状态的发布中复原的数据。

    • 它重新定义了一种 OP_SUCCESSx 操作码，而不是一种 OP_NOPx 操作码。重新定义 OP_NOPx 操作码的软分叉必然是 VERIFY 操作码，在执行失败时就将交易标记为无效。而重新定义 OP_SUCCESSx 操作码的软分叉可以直接在执行后在堆栈中放置 1（表示成功）或者 0（表示失败）；这让它们在一些情形下可以直接使用，而重新定义的 OP_NOPx 则必须用 OP_IF 语句这样的条件来封装。

    • “它防止了与 …… scriptSig 一起造成的惊吓”（详见周报 #361）

    Brandon Black 在回复中将该提议与他早先的 LNHANCE 捆绑提议（详见周报 #285）相比较，发现两者在绝大部分方面是类型的，虽然他指出，该提议在 拥堵控制（一种形式的推迟支付批量处理）用法中链上空间效率较差。

  • ● 允许更长时间的相对时间锁：开发者 Pyth 在 Delving Bitcoin 论坛中发帖建议允许 BIP68 相对时间锁的最大长度从当前的 1 年延长到大约 10 年。这将需要一次软分叉，还要在交易输入的 sequence 字段使用额外的一个比特。

    Fabian Jahr 回复了让时间锁变得太长可能导致资金损失的顾虑，比如，因为量子计算机的开发（或者，我们补充一句，因为上文所述的 Jameson Lopp 的量子抵抗协议的开发）。Steven Roose 指出，长时间时间锁已经能够使用其它时间锁机制来做到了（比如，使用预签名交易和 BIP65 CLTV）。而 Pyth 补充说，它们的目标用途是一条钱包复原路径：长时间锁只会在主要路径变得不可用时派上用场，此时，另一种结局只剩资金永久丢失了。

  • ● 使用 taproot 作为一种承诺方案，安全抵抗量子计算机：Tim Ruffing 的帖子链接了一篇他撰写的论文，分析了 taproot 承诺抵抗量子计算机篡改的安全性。他检验了 tapscript 的 taproot 承诺是否还能继续持有像对抗传统计算机那样的 绑定 和 隐藏 属性。他的结论是：

    量子攻击者需要执行至少 2^81 次 SHA256 求值，才能以 1/2 的概率创建一个 Taproot 输出、并用意料之外的默克尔根来打开这个输出。如果攻击者的量子计算机的 SHA256 计算的最长序列限制在 2^20 ，那么 TA 需要至少 2^92 台这样的机器，才能让成功率达到 1/2 。

    如果 taproot 承诺可以抵抗量子计算机的篡改，那么只需禁用 taproot 密钥花费、向 tapscript 添加抗量子签名检查操作码，就可以向比特币添加量子抗性。Ethan Heilma 在 Bitcoin-Dev 邮件组中发布的帖子，对 BIP360 “支付到量子抗性哈希值” 的最新更新，作出的正是这样的变更。

新版本和候选版本

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

重要的代码和说明书变更

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

  • ● Bitcoin Core #29954 通过加入两个转发策略字段到其响应对象中，延申了 getmempoolinfo RPC：permitbaremultisig（节点是否转发裸多签名输出）和 maxdatacarriersite（交易池中一笔交易的 OP_RETURN 输出可允许的合并最大字节量）。其他策略标签，比如 fullrbf 和 minrelaytxfee，已经暴露了，所以添加的字段实现了完整的转发策略快照。

  • ● Bitcoin Core #33004 默认启用 -natpmp 选项，允许通过 “端口控制协议（PCP）” 的自动端口转发，并带有 “NAT 端口映射协议（59）”的后备机制（详见周报#323）。在支持 PCP 或 NAT-PMP 的路由器背后的监听节点，都可访问，无需手动配置。

  • ● LDK #3246 允许使用 offer 的 signing_pubkey 作为目的地、不使用盲化路径来创建 BOLT12 Offer 和退款。create_offer_builder 和 create_refund_builder 函数现在将盲化路径的创建委托给 MessageRouter::create_blinded_paths；在其中，调用者可以通过传入 DefaultMessageRouter 来生成一条紧凑的路径、传入 NodeIdMessageRouter 来生成全长度的公钥路径，或传入 NodeIdMessageRouter 来生成空路径。

  • ● LDK #3892 将 BOLT12 发票的默克尔树签名公开暴露，允许开发者构建命令行工具或其他软件来验证签名和重新创建发票。这项 PR 还添加了一个 OfferId 字段到 BOLT12 发票中，以跟踪源头 offer 。

  • ● LDK #3662 实现了 BLIPs #55，也被称作 “LSPS05”，它定义了客户端如何通过一个端点（endpoint）来注册 webhook，从而可以接收来自一个 LSP 的通知。这个 API 暴露了额外的端点，让客户端可以列出所有的 webhook 注册，还可以移除具体的一个。在接收异步支付时，获得通知到客户端来说很有用。