本周的 Newsletter 宣布了最新版本的 Eclair 发布，并描述了一个针对闪电网络（LN）的潜在路由改进。此外，还包括我们常规的关于 Bech32 发送支持的部分，以及流行比特币基础设施项目中的值得注意的代码变更。

行动项

本周无内容。

新闻

• ● Eclair 0.3.1 发布： 最新版本的这款 LN 软件包含新的和改进的 API 调用，以及其他使其性能更快、内存占用更少的更改。推荐升级。

• ● 即时路由和免费通道再平衡的头脑风暴： 有时 LN 节点会拒绝接受路由的支付，因为该支付的出站通道目前余额不足以支持该支付。Rene Pickhardt 之前提出了即时路由（JIT）方案，其中节点会尝试将资金从其其他通道余额中移到该通道中。如果成功，则支付可以继续路由；否则，支付将像往常一样被拒绝。由于路由支付可能由于其他原因失败，从而使路由节点无法获得任何费用，因此任何 JIT 再平衡操作都需要免费，否则可能会导致节点因攻击者的利用而蒙受损失。

  在 Lightning-Dev 邮件列表上的一篇新帖子中，化名为 ZmnSCPxj 的 LN 开发者描述了其他最大化利润的节点可能允许免费再平衡的两种情况。第一种情况是观察到路径中的下一个跳点节点如果支付成功将会从支付者那里收到其路由费用。ZmnSCPxj 描述了一种方法，下一跳的节点可以将其再平衡操作与收到路由收入挂钩，确保他们要么获得报酬，要么再平衡不会发生。这需要节点之间的额外通信，因此可能需要进一步讨论以将其考虑纳入 LN 规范。

  ZmnSCPxj 描述的第二种情况是再平衡路径中的其他节点本身希望将一个或多个通道重新平衡到与路由节点相同的方向。这些节点可以允许在该方向上免费路由，以鼓励其他人进行再平衡。第二种情况不需要对 LN 规范进行任何更改：节点已经可以将其路由费用设置为零，从而允许其他节点尝试使用免费再平衡进行即时路由。最坏的情况是，支付本来就会失败，只是需要更长时间返回一个失败消息给支付者，而这段延迟时间等于任何路由节点尝试重新平衡其通道以支持支付所花费的时间。

Bech32 发送支持

第 24 周中的第 17 周，这一系列旨在让您支付的对象可以访问隔离见证的所有好处。

正如我们在本系列早前部分中展示的那样，Bech32 地址在几乎所有方面都优于传统地址——它们允许用户节省费用、更容易转录、可以定位地址输入错误，并且在 QR 码中更高效。然而，有一个特性是传统 P2PKH 地址支持但原生 Segwit 钱包尚未广泛支持的——消息签名功能。为了全面披露信息，并希望能激励钱包开发者采取行动，我们将探讨 Bech32 地址支持中缺失的这一部分。

作为背景，许多钱包允许用户使用传统的 P2PKH 地址，通过与该地址相关联的私钥签署任意文本消息：

$ bitcoin-cli getnewaddress "" legacy
125DTdGU5koq3YfAnA5GNqGfC8r1AZR2eh

$ bitcoin-cli signmessage 125DTdGU5koq3YfAnA5GNqGfC8r1AZR2eh Test
IJPKKyC/eFmYsUxaJx9yYfnZkm8aTjoN3iv19iZuWx7PUToF53pnQFP4CrMm0HtW1Nn0Jcm95Le/yJeTrxJwgxU=

不幸的是，目前没有广泛实施的方式可以为传统 P2SH、P2SH 封装的 Segwit 或原生 Segwit 地址创建签名消息。在 Bitcoin Core 和许多其他钱包中，尝试使用除传统 P2PKH 地址以外的任何地址都会失败：

$ bitcoin-cli getnewaddress "" bech32
bc1qmhtn8x34yq9t7rvw9x6kqx73vutqq2wrxawjc8

$ bitcoin-cli signmessage bc1qmhtn8x34yq9t7rvw9x6kqx73vutqq2wrxawjc8 Test
error code: -3
error message:
Address does not refer to key

一些钱包确实支持 Segwit 地址的消息签名——但采用了非标准化的方法。例如，Trezor 和 Electrum 钱包分别提供了对 P2WPKH 和 P2SH 封装的 P2WPKH 地址的消息签名支持。然而，这两个实现是独立完成的，并且使用了略有不同的协议，因此它们无法验证由另一个系统生成的签名。此外，我们所知的所有钱包所使用的算法都无法轻松适配用于多签名和其他高级限制的 P2SH 和 P2WSH 脚本。这意味着目前的消息签名功能普遍仅限于单签名地址的用户。

有一个提议的标准应允许任何地址类型或脚本用于创建签名消息，BIP322. 该协议甚至应与未来的 Segwit 版本向前兼容，例如 bip-taproot 和 bip-tapscript（但存在一些与时间锁相关的未解决限制）。不幸的是，尽管该提议在一年多前首次提出（参见 Newsletter #13），但至今仍没有任何实现——甚至没有一个正在审查中的提议实现。

这使得 Segwit 用户无法获得与传统地址用户相同级别的消息签名支持，这可能是某些用户不愿意迁移到 Segwit 地址的原因之一。除了钱包放弃消息签名支持外，唯一的解决方案是钱包开发者就一个标准达成一致并广泛实施该标准。

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

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

• ● Bitcoin Core #15427 扩展了 utxoupdatepsbt RPC，添加了一个 descriptors 参数，该参数接受一个[输出脚本描述符]，并使用它来更新 BIP174 部分签名的比特币交易（PSBT），以获取与交易相关的脚本（地址）信息。这是对之前 RPC 行为的补充，之前的行为是从节点的内存池和 UTXO 集中添加信息。此新功能对于硬件钱包和其他配对钱包特别有用，因为它可以将 HD 密钥路径信息添加到 PSBT 中，使得钱包在签署 PSBT 时可以轻松派生出所需的密钥或验证找零输出是否确实支付回了钱包。

• ● Bitcoin Core #16257 当其费率高于 maxtxfee 配置选项设置的最大金额（默认值：0.1 BTC）时，终止向未签名交易中添加资金。之前，资金代码会悄悄地将费用降低到最大值，这可能导致用户在交易中输入错误时多支付高达 1200 美元的费用（按当前价格计算）。新行为让用户有机会修正错误，避免任何资金损失。

• ● Eclair #1045 增加了对 Tag-Length-Value（TLV）消息编码的支持。LN 实现计划未来将大部分消息转移到此格式。LND 和 C-Lightning 之前已实现 TLV 支持。