本周的周报介绍了围绕 “闪电通道拼接” 提议的讨论，并给出了一份提议相关交易术语的 BIP 的链接。此外还有我们的常规部分：最近一次 Bitcoin Core PR 审核俱乐部会议的总结、软件的新版本和候选版本的公告 —— 包括 libsecp256k1 库的一个安全更新 —— 以及热门的比特币基础设施软件上出的重大变更的介绍。

新闻

  • ● 通道拼接技术规范讨论：本周内，多位闪电网络的开发者在 Lightning-Dev 邮件组中讨论了开发中的 “通道拼接” 规范草案，这种技术让一个链下的闪电通道中的一些资金可以在链上花费（称为 “splice-out”）、或者链上的资金可以添加在一条链下的通道中（称为 “splice-in”）。在链上的拼接交易等待足够多的区块确认期间，被操作的通道可以不受中断、持续运行。

    Splicing transaction flow

    本周内出现的讨论有：

    • ● 要发送哪个承诺签名： 在实施拼接时，参与者节点将持有平行的承诺交易，一笔花费通道原来的注资交易输出，另一笔为所有未完结的拼接操作花费每一个新的注资输出。每次通道状态更新时，所有平行的承诺交易都需要更新。简单的处理办法是为单笔承诺交易发送相同的信息并不断重复、每一个平行的承诺交易都需要一条消息。

      这就是原来的通道拼接规范草案的处理办法（见周报 #17 和周报 #146）。但是，就像 Lisa Neigut 在本周说的，创建一次新的拼接操作需要签名新的派生承诺交易。在当前的规范草案中，发送任何一个签名都需要发送对所有其它最新的承诺交易的签名。这是多余的：对这些其它承诺交易的签名都已经发过了。此外，在当前的闪电网络协议中，各方承认自己从对手处收到了一个签名的办法是发回上一笔承诺的交易的 “撤销点（revocation point）”。此处，这些信息又是已经发送过的。在此发送签名和旧的撤销点没有坏处，但需要额外的带宽和处理能力。好处在于，对所有的情形都执行相同的操作，可以让规范保持简洁，可以降低实现和测试的复杂性。

      另一种办法是，在特定情况下，仅为新的承诺交易发送尽可能少的签名（在谈判新的拼接操作的时候），加上一个已经收到签名的承认表述。这会高效得多，虽然这会增加一些复杂性。值得指出的是，闪电节点们只需要管理平行的承诺交易，直到一笔拼接交易得到足够多的区块确认，让两方都认可它是安全的。此后，他们就可以回到只需发送一笔承诺交易的操作模式中。

    • ● 相对数量与零确认的拼接：Bastien Teinturier 发帖讨论了多项提议中的规范变更。除了上述的承诺签名协议的变更以外，他还建议拼接提议使用相对数量，例如 “20 0000 sats” 表示 Alice 将注入 20 0000 聪，而 “-5 0000 sats” 表示她将取走这个数量。他也提出了一种顾虑，关系到零确认的通道拼接交易，但没有深入讨论。

  • ● 交易术语 BIP：Mark “Murch” Erhardt 在 Bitcoin-Dev 邮件组中提出了一份信息型 BIP，提出了一份用于指称交易的不同部分以及相关概念的术语表。截至本文撰写之时，所有的回复都表示支持这项工作。

Bitcoin Core PR 审核俱乐部

在这个月度栏目中，我们会总结最新一期 Bitcoin Core PR 审核俱乐部 会议的成果，列出一些重要的问题和回答。点击问题，即可看到会议对该问题的回答总结。

“不为剪枝模式下的 assumed-valid 区块下载 witness 数据” 是 Niklas Gögge（dergoegge）提出的一项 PR，通过在配置成 “修剪区块数据” 模式的节点不为 “assumevalid” 区块下载 witness（见证）数据，提升初始化区块下载（IBD）的性能。这项优化也在最近的一个stack exchange 问答中讨论过。

  • 启用了 assume-valid 选项但不是剪枝模式的节点也需要下载（非近期的）见证数据吗？如果这些节点不会检查这些数据的话，为什么要下载呢？这个 PR 是否也应该禁止非剪枝模式下的见证数据下载？

    需要见证数据，是因为对等节点可能会跟我们请求非近期的区块（我们对外宣称我们是非剪枝的节点。） ➚

  • 这项措施能在 IBD 期间节约大概多少带宽呢？换句话说，截至最近的一个区块（比如高度为 781213 的区块），所有见证数据的总体积是多少？

    110.6 GB，大概是所有区块数据的 25%。一位参与者之时，110 GB 是他的互联网服务每个月下载流量上限的 10%，所以是巨大的节约。参与者们也预期，因为近期出现的对见证数据的扩展用法，节约的比例会继续升高。 ➚

  • 这项提升能减少自创世区块以来所有区块的数据下载量吗？

    不行。只有自隔离见证激活（区块高度 481824）以来的区块才能减少下载量；隔离见证以前的区块没有见证数据。 ➚

  • 这项 PR 实现了两个重大变更，一个是区块请求逻辑的，另一个是区块验证的。能否具体讲讲？

    在验证过程中，在脚本检查被跳过时，见证数据默克尔树检查也会被跳过。在区块请求逻辑中，从拉取标签中移除 MSG_WITNESS_FLAG，这样对等节点就不会向我们发送见证数据。 ➚

  • 没有这项 PR 的话，assume-valid 选项下会跳过脚本验证，但其它跟见证数据有关的检查不会跳过。那么，这项 PR 导致哪些检查跳过了？

    coinbase 默克尔树根、见证数据体积、见证数据堆栈上限，以及区块重量。 ➚

  • 这项 PR 没有包含用于跳过上一个问题中的所有额外检查的显式代码。这是怎么做到的？

    事实是，当我们没有任何见证数据的时候，所有这些额外的检查都会跳过。这样做的意义在于隔离见证是一次软分叉。有了这项 PR，我们本质上是在假装我们是一个前隔离见证节点（直至我们到达 assume-valid 的终点。） ➚

新版本和候选版本

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

  • ● Libsecp256k1 0.3.1 是一项安全更新，它修复了一个漏洞：相关代码应该在常量时间内运行，但使用 Clang 版本 14 及更高版本编译代码时，却没有这样运行。这个漏洞可能会影响应用，使它们面临时序旁路攻击。作者强烈建议大家升级受到影响的应用。

  • ● BDK 1.0.0-alpha.0 是 BDK 的重大更新的一个测试版本，我们在Newsletter #243 中描述过。建议下游项目的开发者开始集成测试。

重大的代码和文档变更

本周出现重大变更的有：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 #6012 在用于编写 CLN 插件（见周报 #26）的 Python 库中实现了多项重大优化，使得它能跟 CLN 的 gossip 仓库更好地协作。这项变更允许为 gossip 开发更好的分析工具，而且让使用 gossip 数据的插件的开发变得更加容易。

  • ● Core Lightning #6124 添加了一项功能，可以禁止某些使用 commando 功能的用户（runes），并维护一个所有用户的清单，这可用于追踪和禁用遭到爆破的用户。

  • ● Eclair #2607 添加了一种新的 PRC listreceivedpayments，可以列出节点收到的所有支付。

  • ● LND #7437 已支持备份单个通道到一个文件中。

  • ● LND #7069 允许一个客户端向自己的瞭望塔发送一条消息，请求删除某个会话。这使得瞭望塔可以停止监控使用过期状态来关闭通道的链上交易。这降低了瞭望塔和客户端双方的存储和 CPU 负担。

  • ● BIPs #1372 为 MuSig2 协议分配了编号 BIP327，该协议用于创建可用于 taproot 及其它兼容 BIP340 的Schnorr 签名系统的多签名。如该 BIP 所述，使用该协议的好处包括非交互式的密钥聚合以及仅需两轮通信即可完成签名。使用额外的步骤，也可以在参与者之间实现非交互的签名。该协议兼容任何多签名方案的所有好处，例如大大减少链上数据并加强隐私性 —— 既包括参与者自己的，也包括网络所有用户的。