本周的 Newsletter 宣布了 LND 0.8.2-beta 的发布，呼吁帮助测试最新的 C-Lightning 候选发布版本，讨论了 LN 中对基础多路径支付的广泛支持，提供了关于 bech32 错误检测可靠性的更新，汇总了提议的 OP_CHECKTEMPLATEVERIFY 操作码的更新，并链接了一场关于日蚀攻击对 LN 通道影响的讨论。此外，我们还包括了定期的有关受欢迎的比特币基础设施项目、服务和客户端软件的更改，以及 Bitcoin Stack Exchange 精选问答部分。

行动项

  • ● 升级到 LND 0.8.2-beta： 该版本 包含了若干错误修复和小的用户体验改进，最显著的是静态通道备份的恢复改进。

  • ● 帮助测试 C-Lightning 0.8.0 RC： 下一个版本的 C-Lightning 的候选发布版本 已将默认网络切换为主网而非测试网（见 Newsletter #75），并增加了对基础多路径支付的支持（下文将介绍），还有许多其他功能和错误修复。

  • ● 审查 bech32 行动计划： 如下文描述，Pieter Wuille 建议将所有 bech32 地址限制为 20 字节或 32 字节的见证程序，以防止因涉及以 p 结尾的地址的抄录错误导致的资金损失。此规则已经适用于用于 P2WPKH 和 P2WSH 的 v0 segwit 地址，因此此更改只是将其扩展到 v1 及以上的保留用于未来升级的地址（如提议的 taproot）。这将需要已实现 bech32 发送支持的钱包和服务升级其代码，但应当只需要非常小的改动；例如，对于 Python 参考实现，可能看起来像这样：

      --- a/ref/python/segwit_addr.py
  +++ b/ref/python/segwit_addr.py
  @@ -110,7 +110,7 @@ def decode(hrp, addr):
           return (None, None)
       if data[0] > 16:
           return (None, None)
  -    if data[0] == 0 and len(decoded) != 20 and len(decoded) != 32:
  +    if len(decoded) != 20 and len(decoded) != 32:
           return (None, None)
       return (data[0], decoded)

    如果你对该建议更改有任何问题或疑虑，请回复下文 新闻 部分链接的邮件列表帖子。

新闻

  • ● LN 实现增加多路径支付支持： 在大量讨论和开发之后，Optech 跟踪的所有三个 LN 实现现在都增加了对多路径支付的基础支持（合并：C-Lightning、Eclair、LND）。多路径支付由多个 LN 支付组成，这些支付通过不同路径路由，接收者可以同时领取这些支付。这极大提升了 LN 的可用性，允许用户在同一个总体支付中使用多个通道的资金。此升级意味着支出者不再需要过多担心每个特定通道中的余额，因为他们可以跨所有通道发送其全部可用余额（受其他 LN 限制的影响）。

  • ● bech32 错误检测分析： Pieter Wuille 向 Bitcoin-Dev 邮件列表发送了一封邮件，跟进了之前 Newsletter 中描述的 bech32 易变性问题（#72、#74、#76），即在 bech32 字符串末尾的 p 字符前可以随意添加或删除任意数量的 q 字符。Wuille 的分析显示这是 bech32 错误检测属性的唯一例外，“更改 bech32 中的一个常量即可解决该问题。”

    Wuille 计划修订 BIP173 以描述该弱点，提议将现有的 bech32 地址使用限制为 20 字节或 32 字节的见证程序有效载荷，并为非比特币使用和未来可能需要 20 字节或 32 字节以外见证程序的情况定义一个修改后的 bech32 版本。

  • ● 提议的 bip-ctv 变更： Jeremy Rubin 建议 对提议的软分叉新增操作码 OP_CHECKTEMPLATEVERIFY (CTV) 进行若干修改。最显著的是，修改将移除 CTV 模板不能通过比特币脚本从其他数据派生的限制。此更新简化了 Newsletter #75 中讨论的脚本语言修改。据我们所知，这些更新不会对 CTV 的行为产生任何重大影响，也不会对先前描述的用例有显著影响（但我们鼓励任何发现根本性变化的人在邮件列表中进行讨论）。

  • ● LN 节点的日蚀攻击讨论： Antoine Riard 向 Lightning-Dev 邮件列表发布 了两种针对 LN 用户的攻击描述，当用户遭遇日蚀攻击且攻击者延迟中继区块时，这些攻击可能发生。日蚀攻击是指全节点或轻量客户端的所有连接都被单个攻击者控制，这在攻击者是 ISP 或者攻击者控制了用户的路由器时很容易发生。这样攻击者就可以完全控制节点或客户端发送或接收的数据。在第一次攻击中，日蚀攻击者可以发送已撤销的承诺交易，而诚实的用户在得知此消息前无法提交相应的惩罚交易，从而允许攻击者窃取诚实用户的资金。在第二次攻击中，攻击者阻止诚实的用户意识到需要广播最新的承诺交易，因为其 HTLC 即将到期——这使攻击者可以在 HTLC 到期后窃取资金。

    Riard 的帖子以及 Matt Corallo 和 ZmnSCPxj 的回复讨论了过去和现在的工作，以提高全节点和轻量客户端抵御日蚀攻击的能力。对于有兴趣深入了解日蚀攻击及其缓解措施的读者，强烈建议阅读 Bitcoin Core 审查俱乐部上周的会议记录和日志，他们深入讨论了这一主题。

服务和客户端软件的变更

在这个月度专栏中，我们重点介绍比特币钱包和服务的有趣更新。

  • ● Bitfinex 支持 LN 存取款： 在最近的博客文章中，Bitfinex 宣布他们的交易所支持闪电网络。Bitfinex 的用户现在可以使用 LN 存取款资金。

  • ● BitMEX Research 推出了 LN 惩罚交易追踪器： 在 BitMEX Research 发布的文章中，开源工具 ForkMonitor 现在列出了闪电网络的惩罚交易。该工具还通过监控不同比特币实现和版本的 chaintips 来检测分叉。

  • ● BitMEX 支持 bech32 发送： 在最近的博客文章中，BitMEX 宣布他们的交易所支持发送到本机 bech32 地址。文章还概述了他们计划将其钱包从 P2SH 迁移到 P2SH 封装的 segwit 地址。

  • ● Unchained Capital 开源了多重签名协调器 Caravan： 通过一篇博客文章和演示视频，Unchained Capital 开源了他们的多重签名协调器 Caravan。Caravan 是一个无状态的 Web 应用程序，支持使用各种外部密钥库创建和消费多重签名地址。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找问题答案的首选平台之一——或者当我们有空时，帮助那些好奇或困惑的用户。在这个月度专栏中，我们重点介绍了自上次更新以来发布的最高票问题和答案。

值得注意的代码和文档更改

本周 Bitcoin Core、C-Lightning、Eclair、LND、libsecp256k1、比特币改进提案（BIPs）和闪电网络规范中的值得注意的更改。

  • ● Bitcoin Core #17678 增加了对 S390X 和 64 位 POWER CPU 架构的编译支持。

  • ● Bitcoin Core #12763 添加了 RPC 白名单功能，允许你限制特定用户可以运行的 RPC。默认情况下，任何已认证的用户都可以运行任何命令，但新的配置选项 rpcwhitelist 和 rpcwhitelistdefault 可用于配置哪些用户可以访问哪些 RPC。

  • ● C-Lightning #3309 增加了对多路径支付的支持，正如上文新闻部分中描述的那样。

  • ● LND #3697 将新通道的默认最小 HTLC 值设置为 1 millisatoshis (msat)，低于之前的默认值 1,000 msat。HTLC 的最小值在通道打开后无法更改，因此此更改允许使用此设置的通道接受亚聪支付。[编辑：该段的先前版本错误地声称新最小值为 0 msat；正确值应为 1 msat。]

  • ● LND #3785 基本修复了 Newsletter #74 中提到的问题，即 C-Lightning 和 LND 对相同消息使用不同格式，导致解析错误和断开连接。

  • ● LND #3702 扩展了 closechannel RPC，增加了一个 delivery_address 参数，可以用来请求共同关闭通道并将资金发送到指定地址。如果用户之前启用了上周的 Newsletter 中描述的前置关闭脚本功能，该方法将无法使用。

  • ● LND #3415 允许通过多路径支付结算发票，增加了 LND 中对基础多路径支付支持所需的最终代码（参见上文 新闻 部分中关于多路径支付的描述）。

  • ● BOLTs #643 增加了基础多路径支付支持，正如上文新闻部分中描述的那样。这实现了在一年前的闪电规范 1.1 会议期间设定的主要目标之一，以帮助显著改善 LN 钱包用户体验。

节假日出版安排

我们将不会在 12 月 25 日或 1 月 1 日发布 Newsletter。相反，我们将在 12 月 28 日星期六发布第二期年度回顾特别报告。常规 Newsletter 将于 1 月 8 日星期三恢复发布。

节日快乐！