本周的新闻部分宣布了一个在描述符中索引不可花费密钥的 BIP 草案、测验了各实现在如何使用 PSBTv2，以及深入纠正了我们上周对新的链下 DLC 协议的介绍。此外是我们的常规栏目：介绍服务和客户端软件的变更、宣布软件的新版本和候选版本，总结热门的比特币基础设施软件的新变更。

新闻

  • ● 在描述符中索引不可花费密钥的 BIP 草案：Andrew Toth 在 Delving Bitcoin 论坛和 Bitcoin-Dev 邮件组 中发布了一份关于在描述符中索引可证明不可花费的密钥的 BIP 草案。这项工作跟随了以往的谈论（详见周报 #283）。使用一个可证明不可花费的公钥，也叫 “此中无后门（NUMS）” 点，跟 taproot 内部公钥的关系最密切。如果不可能使用内部公钥创建密钥路径花费，那么就只可能创建使用某个脚本树叶子的脚本路径花费（例如，使用一个 tapscript）。

    截至本刊发布之时，该 BIP 草案的 PR 页面还在发生活跃的讨论。

  • ● PSBTv2 集成测试：Sjors Provoost 在 Bitcoin-Dev 邮件组中发帖询问那些软件已经实现对版本 2 的 “待签名比特币交易（PSBTs）” 数据格式（详见周报 #141）的支持，以测试一项为 Bitcoin Core 添加支持的 PR 。一个更新后的支持软件清单可以在 Bitcoin Stack Exchange 网站中找到。我们发现了两个有意思的回复：

    • ● 默克尔化的 PSBTv2：Salvatore Ingala 解释道，Ledger Bitcoin 应用会将一项 PSBTv2 数据的各字段转化成一棵默克尔树，并且最初仅发送树根到 Ledger 硬件签名器。在需要具体字段时，再发送数值以及相应的默克尔树证据。这让设备可以安全地跟每一段信息独立工作，而无需再有限的内存中存储完整的 PSBT 数据。在 PSBTv2 可以做到，是因为它已经将待签名交易的部分分割到了不同的字段中；而对初版的 PSBT 格式（v0），这就需要额外的解析。

    • ● 静默支付 PSBTv2：BIP352 指定 “静默支付” 显式地依赖于 解释道 PSBTv2 规范。Andrew Toth 解释道，静默支付需要 v2 的 PSBT_OUT_SCRIPT 字段，因为静默支付所需使用的输出脚本，在所有输入的签名人处理完这个 PSBT 之前，是无法知晓的。

  • ● 关于链下 DLC 的勘误：在上周新闻部分对链下 DLC 的介绍中，我们混淆了由开发者 conduition 提出的新方案，与此前已经发布并得到实现的链下 DLC（谨慎日志合约）方案。它们有以下重大且有趣的区别：

    • 周报 #174 和 LN-Penalty 所提到的 DLC 通道 协议使用了一种类似于 LN-Penalty 的 “先承诺后撤销（commit-and-revoke）” 机制：各参与者先通过签名来 承诺 一个新状态，然后通过释放一个秘密值、允许对手方从本地私有的旧状态（如果真的被发布上链）中完全花费来 撤销 旧状态。这让一个 DLC 可以通过双方的交互来刷新。比如说，Alice 和 Bob 可以这样做：

      1. 立即启动一个打赌一个月后 BTCUSD 价格的 DLC；

      2. 在三周后，同意启动一个打赌两个月后 BTCUSD 价格的 DLC，并撤销前一个合约。

    • 而新的 DLC 工厂 协议则会在合约到期时自动撤销双方在链上发布状态的能力，因为合约的任何断言机（oracle）见证，都可以作为秘密值，让一方的私有状态（如果被发布上链）被对方完全花费。实际上，这就自动取消了旧状态，让工厂从建立之始就可以签名连续的 DLC，无需任何额外的交互。比如说，Alice 和 Bob 可以这样做：

      1. 立即开启一个打赌一个月后 BTCUSD 价格的 DLC；

      2. 同时立即开启一个打赌两个月后 BTCUSD 价格的 DLC，使用一个交易时间锁来防止它在一个月内发布。他们还可以重复这一技巧，从而建立三个月后、四个月后 …… 到期的合约。

    在 DLC 通道协议中，Alice 和 Bob 不能同时创建两个合约：必须在准备好撤销第一个合约之后，才能创建第二个合约，这就需要在某个时间发生交互。而在 DLC 工厂协议中，所有合约都可以在工厂建立时就创建，而且不需要额外的交互；不过，任何一方都依然可以将最新的 “安全可发布” 交易版本发布到链上，从而中断这一系列的合约。

    如果工厂的参与者们可以在合约建立之后交互，就可以延伸这份合约 —— 但他们无法决定使用另一份合约，或其他断言机，除非以前签名过的所有合约都已经到期（或他们使用一次链上操作）。虽然有可能消除这一缺点，这就是它（相比 DLC 通道协议）削减交互需求的代价（在 DLC 通道协议中，合作撤销可以随时任意改变合约）。

    感谢 conduition 提醒我们在上周新闻部分犯下的错误，并耐心地回答我们的问题。

服务和客户端软件的变更

在这个月度栏目中，我们会突出比特币钱包和服务的有趣更新。

新版本和候选版本

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

  • ● BTCPay Server 2.0.6 包含了一项 “安全修复，针对使用自动化支付处理器在链上处理 退款/拉取支付 的商家”。此外还有多项新特性和 bug 修复。

重大的代码和文档变更

重大更新出现在：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 #31397 通过跟踪和使用所有可以提供缺失父交易的潜在对等节点，优化孤儿交易确定程序。以往，这个确定程序仅依赖于最初提供孤儿交易的对等节点；如果该对等节点不响应或返回一个 notfound 消息，程序是没有重试机制的，导致可能的交易下载失败。新方法尝试从所有候选的对等节点处下载父交易，同时保持带宽效率、抗审查性以及实质的负载均衡。这对 “一父一子（1p1c）”交易宝转发尤其有好处，并且为 BIP331 的 “接受方发起的祖先交易宝转发” 奠定了基础。

  • ● Eclair #2896 启用了 MuSig2 的对等节点碎片签名存储，而不是传统的 2-of-2 多签名的存储，作为未来实现 “简单 taproot 通道” 的前置。存储该碎片签名允许一个节点在需要时单方面广播一笔承诺交易。

  • ● LDK #3408 引入了在 ChannelManager 中创建静态发票及其对应的 offers 的用法，以支持在 BOLT12 中实现异步支付，如 BOLTs #1149 的规定。常规的 offer 创建用法要求接收者在线以服务发票请求，这种新方法则适合经常离线的接收者。这项 PR 也为给静态发票支付（详见周报 #321）添加了缺失的测试，并保证当接收者回到线上时，发票请求是可以检索的。

  • ● LND #9405 让 ProofMatureDelta 参数变成可配置的，该参数决定 gossip 网络中的一条 通道宣告 在得到处理之前需要积累多少确认数量。默认数值是 6 。