本周的 Newsletter 记录了 Bitcoin Core 共识逻辑的变化,并宣布了 Optech 网站上用于追踪不同钱包和服务之间技术采用情况的新功能。此外,还包括我们常规的关于 Bech32 发送支持和流行比特币基础设施项目值得注意的变更部分。

行动项

  • 升级到 C-Lightning 0.7.2.1:版本包含若干错误修复以及插件管理的新功能,并支持正在开发的测试网替代方案 Signet。

新闻

  • 硬编码先前软分叉激活的区块高度:两个先前软分叉激活的区块高度现已被硬编码到 Bitcoin Core 中,作为这些分叉激活的时间点。这意味着任何超出这些区块的区块链重组都可能在具有此硬编码的节点与没有此硬编码的节点之间产生链分裂。然而,这样的重组需要的工作量证明大致等于当前所有活跃比特币矿工一年的总产出(以撰写时为准),因此被认为极不可能发生,并且即使发生也意味着一种可能阻碍共识形成的威胁。此次硬编码与几年前 BIP90 硬编码类似,简化了 Bitcoin Core 的共识代码。有关更多信息,请参见邮件列表帖子PR #16060

  • 新的 Optech 兼容性矩阵:Optech 网站上的一个新功能显示了哪些钱包和服务支持某些推荐功能,目前包括可选的 Replace-by-Fee (RBF) 和 Segwit(未来计划添加更多比较)。该矩阵旨在帮助开发者评估功能支持的程度,并从早期采用者的设计中学习。详情请参见我们的公告帖子

Bech32 发送支持

这是关于让您支付的人能够访问 Segwit 全部优势的系列中的第 23 周,共 24 周。

本周 Newsletter 的新闻部分介绍了 Optech 网站上的新功能。截至撰写本文时,我们认为从创建和审核兼容性矩阵中获得了一些关于 Bech32 的重要见解。

  • 大多数工具支持支付到 Bech32 地址:调查的 74% 的钱包和服务支持支付到 Segwit 地址。虽然这还不是我们希望看到的近乎普遍的支持,但这已经足够多,可能很快我们会看到更多钱包默认切换为 Bech32 接收地址。

  • 支持 P2WPKH 但不支持 P2WSH:当我们开始测试各种应用时,假设“Bech32 发送支持”是一个二元问题——要么工具支持,要么不支持。然而,我们调查的一个服务支持向本地 Segwit (Bech32) P2WPKH 地址支付资金,但不支持 Bech32 P2WSH 地址。这促使我们分别追踪这两种不同的 Segwit 版本 0 地址。(如果你是开发者,请同时支持这两种地址类型。)

  • 地址输入字段长度限制:某些服务可能支持发送到 Bech32 地址,但当我们尝试输入 Bech32 地址时,要么被拒绝为长度过长,要么字段根本无法接受所有字符。(提醒一下,BIP173 对比特币主网 Bech32 地址长度的说明是:它们“总是介于 14 到 74 个字符之间 [含 14 和 74],并且其长度模 8 不能是 0、3 或 5。”)

  • 输入字段的截图:我们记录了尝试发送到 Bech32 地址的步骤,收集了大量的截图,供 UI 设计人员在实施他们自己的 Bech32 发送支持(或其他功能,如 RBF 支持)时参考最佳实践。

  • 缺乏 Bech32 找零地址支持:由于支付到 Bech32 地址的支持仍然不普遍,Segwit 兼容钱包默认生成 P2SH 包裹的 Segwit 接收地址是合理的。然而,这些钱包中的许多也使用 P2SH 包裹的 Segwit 地址来接收从自己发给自己的找零。在某些情况下,这可能是出于隐私的考虑(例如,Bitcoin Core 当前尝试使找零输出类型与支付输出类型匹配),但在大多数情况下,这似乎是钱包没有充分利用将找零发送到其自己的 Bech32 地址以节省费用的机会。

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

本周 Bitcoin CoreLNDC-LightningEclairlibsecp256k1比特币改进提案(BIPs)闪电网络规范中的值得注意的变更。

  • Bitcoin Core #16248 扩展了 Bitcoin Core 中的白名单配置选项,允许指定应向哪些 IP 地址或范围提供哪些服务。例如,此更改的动机是允许向特定的节点(如用户自己的轻量钱包)提供布隆过滤器,即使过滤器默认被禁用。这可以通过 -whitelist=bloomfilter@1.2.3.4/32 来实现。如果仅提供 IP 地址(即没有指定权限),行为与之前相同。

  • Bitcoin Core #16383 更改了接受 include_watchonly 参数的 RPC 命令,使其在禁用私钥的钱包(即仅作为观察钱包有用的钱包)中自动设置为 True。这确保了观察地址的结果包含在返回结果中。

  • Bitcoin Core #15986 扩展了 Newsletter #34 中描述的 getdescriptorinfo RPC,新增了 checksum 字段。此 RPC 已经会为任何不包含校验和的描述符添加校验和,但它也会通过移除私钥和其他用户可能不想要的更改来标准化描述符。此次合并新增的字段返回用户提供的描述符的校验和。描述符校验和遵循输出脚本描述符 文档中描述的 # 字符后的格式。

  • Bitcoin Core #16060 添加了先前软分叉的硬编码区块高度,详情请参见新闻部分描述

  • LND #3391 总是返回相同的错误消息以避免泄露发票是否存在。有关信息泄露的更多详情,请参见 BOLTs #516 和相关的 BOLTs #608

  • LND #3355 扩展了 GetInfo RPC,增加了一个 SyncedToGraph 布尔值,用于指示节点是否认为自己拥有最新的 gossip 信息,以便高效地进行支付路由。