本周的 Newsletter 公告了 Bitcoin Core 0.18.1 的维护版本发布，总结了关于 BIP174 扩展的讨论，并提到了一项关于 LN 蹦床支付的提案。本周的 bech32 sending support 部分由 BRD 贡献了一个特别的案例研究，而 值得注意的更改 部分则重点介绍了几项可能的重要开发。

行动项

  • ● 在发布二进制文件时升级到 Bitcoin Core 0.18.1： 该维护版本已经打上标签，预计几天内会将二进制文件上传到 bitcoincore.org。此版本提供了多个错误修复和其他改进，建议在二进制文件可用时进行升级。

新闻

  • ● BIP174 的可扩展性： 部分签名的比特币交易 (PSBT) 规范的作者 Andrew Chow 提出了一些用于广泛采用的小改动：

    • ● 为专有用途保留类型： 一些应用程序已经在 PSBT 中包含了未在 BIP174 中指定的数据。提议为私有 PSBT 扩展保留一个类型字节或一组类型字节，类似于为私有网络保留的 IP 地址范围。本周的讨论特别关注了这种机制的具体构建。

    • ● 全局版本号： 虽然设计 PSBT 增强功能的目标是向后兼容，但 Chow 提议向 PSBT 添加一个版本字节，以指示它们使用的最先进功能，以便旧的解析器可以检测它们是否收到可能无法理解的 PSBT。没有明确版本号的 PSBT 将被视为使用版本 0。

    • ● 多字节类型： 为了支持更多类型，提出了多字节类型的建议。邮件列表讨论似乎支持使用与比特币协议中相同的 CompactSize 无符号整数。

  • ● 蹦床支付： Bastien Teinturier 在 BOLTs 仓库中开启了一个拉取请求，并在 Lightning-Dev 邮件列表中发起了讨论，讨论向协议添加对蹦床支付的支持，正如在 Newsletter #40 中描述的那样，付款方将付款发送到一个中间节点，该节点计算路径到另一个中间节点（以增加隐私）或接收节点。这对不想跟踪 gossip 流量的低带宽 LN 客户端（例如移动设备）非常有利，因为它们只知道如何路由到少数节点。发送蹦床支付将需要多个节点之间的协调，因此应在闪电网络规范中进行记录。

Bech32 发送支持

第 24 周中的第 21 周系列，关于允许你支付的对象访问 segwit 的所有优势。

以下案例研究由 Optech 成员公司 BRD 提供，描述了他们在为其钱包实现 bech32 和其他 segwit 技术时的经验。

我们于 2018 年 1 月开始在 BRD 钱包中实现 bech32 支持，在 breadwallet-core 中添加了 bech32 解码和编码支持。breadwallet-core 是一个 MIT 许可的跨平台 C 库，无需外部依赖。我们所有的软件都尽可能避免第三方库的依赖，目前只使用 Pieter Wuille 的 libsecp256k1. 最小化依赖是高安全性加密项目的典型做法。对于 bech32 的实现，我们发现 BIP173 文档非常完善，因此没有遇到复杂的具体问题。

2018 年 3 月，breadwallet-core 更新以自动解析作为比特币地址提供的任何内容，判断它是传统 P2PKH、传统 P2SH 还是 segwit bech32，并自动为每种情况生成相应的 scriptPubKey。这使得 BRD 开始支持向 bech32 地址发送比特币。最终在 2018 年 10 月，我们在整个库的后端和移动应用前端实现了完整的 segwit 支持，允许用户开始接收 bech32 地址，同时将所有找零地址默认设置为 bech32。

我们从未实现对 P2SH 封装的 segwit 地址的接收支持，而是直接使用 bech32。这是为了更好地优化 BRD 用于扫描影响用户钱包交易的布隆过滤器机制。为了允许用户跟踪他们何时收到付款，布隆过滤器会与 scriptPubKey 中的每个数据元素进行匹配。对于给定的公钥，scriptPubKey 中的数据元素在传统 P2PKH 和原生 segwit (bech32) P2WPKH 中是相同的。以下是 Optech 之前使用的一个示例：

  • 地址 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC 的传统 P2PKH scriptPubKey：

    OP_DUP OP_HASH160 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6 OP_EQUALVERIFY OP_CHECKSIG

  • 地址 bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh 的原生 segwit (bech32) P2WPKH scriptPubKey：

    OP_0 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6

由于针对给定元素的布隆过滤器将匹配同一公钥的 P2PKH 和 P2WPKH 地址，BRD 能够以零额外开销的方式扫描这两种支付类型。这也使得实现更加简洁，不会增加提供布隆过滤器服务的公共节点的资源使用。这对于使用其他类型扫描的钱包和服务来说，可能也是一种有价值的优化，因为这可能比 BIP84 推荐的单独 HD 派生路径产生更少的开销。

由 bech32 地址生成的 scriptPubKey 长度各不相同，这会影响需要支付的交易费金额。比特币的手续费计算非常复杂——有时费率在 24 小时内会猛增几个数量级——但这在 segwit 之前已经是事实，所以我们以前花了很多时间在手续费计算上，并使其尽可能灵活。这意味着由 bech32 地址生成的 scriptPubKey 大小的变化不会对 BRD 造成影响。

我们希望今天的应用程序能够适应未来，因此代码支持发送到未来的 segwit 版本（请参阅 Optech 的描述）。这意味着，例如，如果比特币用户选择通过软分叉更改共识规则，BRD 将自动支持支付到 taproot 地址。

一旦真正的势头建立起来，且大多数其他钱包和服务支持发送到 bech32 地址，BRD 的 bech32 接收支持将作为默认设置推广给我们的所有用户。为准备这一过渡，尽可能多的公司和服务自愿支持 bech32 发送能力非常重要。为了推动采用，我们创建了 WhenSegwit 网站并成为 Optech 成员公司。我们希望其他钱包和服务在手续费相对较低时尽快实现完整的 segwit 支持。

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

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

  • ● Bitcoin Core #15911 更改了 walletcreatefundedpsbt，使其在钱包配置为使用 RBF（替换手续费）的情况下，信号 BIP125 RBF。

  • ● Bitcoin Core #16394 更改了 createwallet RPC，使其在传递空字符串作为密码参数时，创建一个未加密的钱包（并打印警告）。

  • ● LND #3184 为 LND 添加了一个瞭望塔客户端子服务器，取代了最近版本中添加的私有瞭望塔实现。

  • ● LND #3164 创建了一个新数据库，存储过去 1,000 笔支付的信息。（默认设置为 1,000，可以更改。）这旨在与 LND 的任务控制功能一起使用，该功能尝试更好地利用过去支付尝试（尤其是失败）的信息，以便为后续支付选择更好的路由。在首次升级到包含此更改的版本时，将从 LND 的低级 HTLC 追踪数据库中填充有关以前支付的详细信息。

  • ● LND #3359 添加了一个 ignore-historical-filters 配置选项，该选项将使 LND 忽略来自对等方发送的 gossip_timestamp_filter。该过滤器允许对等方请求在较早日期范围内会进行 gossip 的所有公告。通过忽略该过滤器的请求，LND 使用较少的内存和带宽。该忽略选项当前默认设置为 False，因此默认的 LND 行为没有变化，但提交评论指出，“未来计划将其默认设置为 True。”

  • ● C-Lightning #2771 允许插件指示它们是否可以在运行时启动和停止，而不仅仅是在初始化时启动和关闭。此信息由一个新的 plugin 命令使用，允许用户执行这些运行时的启动和停止。

  • ● C-Lightning #2892 现在总是从 Lightning 配置目录运行插件，减少了不同安装之间的不一致性，并使插件能够在该目录中存储和访问数据。

  • ● C-Lightning #2799 为插件提供了新的 forward_event 通知，当 HTLC 已被提供、结算、双方失败或本地失败（单方面）时通知。此外，该 PR 还扩展了 listforwards RPC，添加了一个 payment_hash 字段，以便用户找到有关 HTLC 的其他信息。

  • ● C-Lightning #2885 在启动时将与通道对等方的重连间隔开，以减少流量激增导致 C-Lightning 在与对等方连接后重新建立通道所需时间超过 30 秒的可能性。这是导致 LND 发送同步错误消息的问题，正如上周的 Newsletter 所述。

  • ● BOLTs #619 添加了对 LN 洋葱路由中可变大小负载的支持。结合三周前合并到规范中的类型-长度-值（TLV）编码字段（见 Newsletter #55），这使得在中继支付的加密数据包中放入额外数据变得更加容易，从而实现了多个功能的添加（包括本周 Newsletter 中讨论的蹦床支付）。