本周的 Newsletter 总结了关于更新 LN gossip 协议的提案。此外，还包括了我们常规的 bech32 发送支持和流行的比特币基础设施项目中的值得注意的变化。

行动项

本周无行动项。

新闻

  • ● Gossip 更新提案： Rusty Russell 提出了一个简短提案，旨在更新 LN 节点用来宣布其可用于支付路由的通道及其当前支持的功能的 gossip 协议。值得注意的是，该提案通过两种机制显著减少了消息的字节大小：schnorr 签名和可选消息扩展。基于 bip-schnorr 的 Schnorr 签名相比于 DER 编码的 ECDSA 签名，因其更高效的编码节省了一些字节，但在 gossip 改进提案中，最显著的节省来自于使用 MuSig 聚合通道公告的两个签名为单个签名。使用类型-长度-值（TLV）记录的可选消息扩展允许在使用协议默认值时省略不必要的细节（关于 TLV 的更多信息，请参见下文值得注意的代码和文档变更部分）。

Bech32 发送支持

第 24 周中的第 18 周，这一系列旨在帮助您支付的对象享受 segwit 的所有优势。

我们从钱包提供商那里听说，他们对默认接收 bech32 地址的犹豫原因之一是担心会显著增加客户支持请求。尽管如此，一些钱包已经默认使用 bech32 地址，其他一些钱包也计划很快开始使用，例如 Bitcoin Core。

我们向包括 BitGo、BRD、Conio、Electrum 和 Gemini 在内的多家服务商征求了关于使用 bech32 地址对客户支持负担的意见。大多数服务商报告称问题很少（“没有支持请求”和“没有太多困惑”）。

有一家服务商表示：“与比特币地址相关的客户支持票增加了 50%，但票数绝对数量如此之小，可能无法给出太多意义。在 Bech32 出现之前或之后，这个话题的票数从来都不多，所以不确定这是否是让交易所转换的一个重要论点。相反，我可能建议关注费用问题，如果你使用的是旧的钱包实现，费用确实可能会累积。”

Electrum 也确实看到了一些公开的报告，例如[“奇怪的地址”]和[“Localbitcoins 不支持发送到 bech32”]。

尽管结论尚不明确，但令人欣慰的是，选择支持接收 bech32 地址的服务并没有对其客户支持团队产生负面影响。上面关于考虑费用节省的建议可能远远超过了这些担忧，并且与 Bitcoin Optech 的指导一致。鉴于少数负面报告和支持接收 bech32 地址的钱包和服务可以显著节省费用，可能是时候让更多的钱包开始将 bech32 作为默认地址格式。如果这种情况发生，那么其他钱包和服务支持发送到 bech32 地址将变得更加重要。

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

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

  • ● Bitcoin Core #15277 允许 Linux 版本的 Bitcoin Core 使用 GNU Guix（发音为“geeks”）进行确定性编译。这相比目前仍然支持的基于 Gitian 的机制所需设置要少得多，因此希望能促使更多用户能够独立验证发布的二进制文件仅来自于 Bitcoin Core 源代码及其依赖项。此外，Guix 需要的构建环境依赖项更少，并且正在进行的工作旨在从根本上消除它对典型构建工具链中任何预编译二进制文件的需求，这些都使得构建系统更容易审计。总的来说，这应当减少用户对 Bitcoin Core 开发者以及用于构建 Bitcoin Core 的软件的信任需求。尽管该合并的拉取请求目前只构建 Linux 二进制文件，但预计很快会支持 Windows 和 macOS。有关更多信息，请参阅 PR 作者 Carl Dong 最近在 Breaking Bitcoin 会议上的演讲（视频，文字记录）。

  • ● BOLTs #607 扩展了 LN 规范，允许数据包包含以类型标识其用途的记录，后跟消息的长度和记录的值，称为 TLV 记录。由于每条消息都以类型和长度开头，LN 节点可以忽略那些它们不理解的记录类型，例如规范中的可选部分（这些部分可能比节点更新）或仅由节点子集使用的实验记录，这些记录尚未成为规范的一部分。现有的 LN 记录尚未转换为 TLV 格式，但后续添加的可选记录预计将使用此格式。Optech 监控的所有 LN 实现目前都在其开发分支上支持 TLV。

  • ● BIPs #784 更新了 BIP174 部分签名的比特币交易（PSBTs），在全局部分中加入了 BIP32 扩展公钥（xpub）字段。新部分“变更检测”描述了签名钱包如何使用此新字段来识别哪些输出属于该钱包（无论是单独使用还是作为使用多重签名的一组钱包的一部分）。这一规范修改的想法之前在 Bitcoin-Dev 邮件列表中进行了讨论，如 Newsletter #46 所述。