本周的 Newsletter 描述了一项允许在不新开通道的情况下升级 LN 通道承诺交易格式的提案，并包括 River Financial 使用 PSBT 和描述符构建钱包软件的现场报告。还包括了我们常规的栏目：Bitcoin Stack Exchange 精选问答、最近的发布与候选发布以及对流行比特币基础设施项目的值得注意的更改。

行动项

本周无。

新闻

  • ● 升级通道承诺格式： Olaoluwa Osuntokun 本周在 Lightning-Dev 邮件列表中发布了一项建议，提出对 LN 规范进行扩展，允许拥有现有通道的两方协商采用不同格式的新的承诺交易。承诺交易用于允许 LN 节点在链上发布当前的通道状态，但现有协议仅允许节点通过新开通道来升级到新的承诺格式。Osuntokun 的提案允许一个节点向其对等节点发送信号，表示希望切换格式。如果对等节点同意，两个节点将把现有通道状态移植到新格式中，并在未来使用新格式。

    所有讨论的参与者似乎都支持这一基本想法。Bastien Teinturier 建议，最简单的方式是仅允许在通道没有待处理支付（HTLC）的情况下切换承诺格式——这意味着节点需要暂停在特定通道内发送或中继支付以进行升级。

    ZmnSCPxj 指出，同样的基本思路可以用于在链下更新资金交易，例如在实现 taproot 和 SIGHASH_ANYPREVOUT 的情况下，允许使用基于 Eltoo 的通道承诺。在 ZmnSCPxj 的提案中，现有资金交易的输出将支付给一个新的资金交易，该交易保持在链下。如果通道以双边关闭终止，原始资金交易的输出将支付给最终的通道余额；否则，链下的次级资金交易可以发布到链上，并可以使用适当的单边关闭协议解决通道。

现场报告：在 River 中使用 Descriptors 和 PSBT

作者：Philip Glazman，River Financial 工程师

River Financial 是一家专注于比特币金融服务的新兴金融机构。其旗舰产品——比特币经纪业务，为零售投资者提供了一个高接触的平台，方便他们买卖比特币。

River Financial 在其钱包软件中使用了两项技术：部分签名的比特币交易（PSBT） 和输出脚本描述符。采用这些标准的决定使得 River 的钱包操作具有更大的灵活性和互操作性。

将 PSBT 引入钱包栈的决定受到了将密钥签名者视为接口这一理念的影响。PSBT 是由 Andrew Chow 编写的 BIP174 中描述的签名者格式。在此标准之前，没有标准化格式来描述未签名交易。因此，每个签名者都使用特定于供应商的格式，这些格式无法互操作。通过遵循 PSBT 标准，钱包基础设施可以避免供应商锁定，减少签名者逻辑中的攻击面，并对钱包创建的交易有更好的保障。该标准还使得多重签名脚本更安全地使用，因此在操作成本没有显著增加的情况下，大大提高了安全性。

在钱包软件中实施输出脚本描述符的决定极大地减少了钱包操作的复杂性，并提高了功能集的灵活性。描述符是一种描述脚本的语言，由 Pieter Wuille 编写，并在 Bitcoin Core 中使用。在 River 的钱包软件中，描述符语言在从钱包创建到地址生成的多个环节得到了应用。在描述符之前，钱包之间没有互操作的方式来导入它们所使用的脚本的有用信息。通过使用脚本描述符，River 的钱包能够减少启动对脚本、地址或密钥集的监控所需的信息。每个钱包软件中的钱包都有一个关联的描述符，用于创建脚本。这带来了两个直接的好处：

  1. 钱包软件能够使用描述符监控冷钱包，并随后派生新地址。 在我们的旗舰经纪产品中，River 的客户可以创建新的存款地址，将比特币直接存入安全的多重签名冷钱包中。
  2. 创建和导入新钱包非常容易，因为描述符语言可以定义所需的脚本。 River 可以管理许多具有不同脚本的钱包，从而为每个钱包制定独立的安全模型。对于冷钱包，使用 P2WSH 多重签名描述符，而对于热钱包（客户提现），使用 P2WPKH 描述符。独立的钱包使得 River 能够将热钱包中的比特币量保持在绝对最低水平（以降低风险），并更好地管理 UTXO 池以提供提现服务。

使用描述符和 PSBT 标准的决定迄今为止带来了显著的收益，因为它们提供了灵活性和互操作性。这一基础将有助于 River Financial 扩展其钱包基础设施。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找答案的首选之地之一——或者在我们有空时帮助那些好奇或困惑的用户。在这个月度专题中，我们精选了一些自上次更新以来获得最高投票的问题和答案。

发布与候选发布

流行的比特币基础设施项目的新发布和候选发布。请考虑升级到新版本或帮助测试候选发布。

  • ● C-Lightning 0.9.0rc3 是即将到来的一个主要版本的候选发布。它增加了对更新的 pay 命令和新的 keysend RPC 的支持，这些内容在上周的 Newsletter 值得注意的代码更改部分中有所描述。还包括其他多个值得注意的更改和多个错误修复。

  • ● Bitcoin Core 0.20.1rc1 是即将到来的维护版本的候选发布。除了错误修复和由这些修复引起的一些 RPC 行为更改外，计划中的发布还提供了与 HWI 最新版本的兼容性，并支持为手续费超额支付攻击发布的硬件钱包固件。

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

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

  • ● Bitcoin Core #18044 添加了对见证 txid (wtxid) 交易库存公告 (inv) 和请求 (getdata) 的支持，如 BIP339 中所述（见 Newsletter #104）。在此合并之前，所有比特币节点通过交易的 txid 向其对等节点公告新的未确认交易。然而，txid 并不承诺 segwit 交易中的见证数据，因此下载了无效或不需要的 segwit 交易的节点无法安全地假设任何具有相同 txid 的交易也是无效或不需要的。这意味着节点可能会浪费带宽，从每个公告该交易的对等节点重复下载相同的错误交易。

    到目前为止，这还没有成为问题——诚实的对等节点通常不会公告他们自己不接受的交易，所以只有想要浪费其上传带宽的破坏性对等节点才会宣传无效或不需要的交易。然而，如今的一种不需要的交易是 v1 segwit UTXO 的支出——BIP341 taproot 规范计划使用的支出类型。如果 taproot 激活，这意味着较新的支持 taproot 的节点将向较旧的未支持 taproot 的节点公告 taproot 支出。每次这些未支持 taproot 的节点收到一个 taproot 支出交易时，它都会下载该交易，发现它使用了 v1 segwit，然后将其丢弃。这可能会非常浪费网络带宽，对较旧的未支持 taproot 的节点和较新的支持 taproot 的节点都是如此。这同样适用于其他提议的网络中继策略更改。

    在此合并的 PR 中实现的解决方案是通过 wtxid 来公告交易——这包括对 segwit 交易的见证数据的承诺。Bitcoin Core 中的 taproot 实现（见 PR #17977）然后只能通过 wtxid 来中继交易，以防止较新的节点意外向较旧的节点发送垃圾信息。

    然而，在此 PR 合并到 Bitcoin Core 的主开发分支后，在每周的 Bitcoin Core 开发会议期间，关于 taproot 对 wtxid 中继的软依赖是否会使得 taproot 回移到当前的 Bitcoin Core 0.20.x 分支变得更复杂的问题进行了讨论。在会议期间和随后的讨论中提到了四个选项：

    1. 回移 wtxid：如果有 0.20.x taproot 版本，wtxid 中继和 taproot 都将回移。John Newbery 已经创建了一个 wtxid 中继回移。

    2. 不回移 wtxid：只回移 taproot，并接受交易公告将比平常使用更多带宽，直到所有人都升级到使用 wtxid 的节点。

    3. 不中继 taproot：只回移 taproot，但不启用回移节点上 taproot 交易的中继。这防止了立即的带宽浪费，但可能会使得 taproot 支出交易更难到达矿工，并且会降低 BIP152 致密区块的速度和效率。较差的致密区块性能可能会暂时增加矿工创建的孤块数量（尤其是因为公共 FIBRE 网络最近已关闭）。

    4. 不回移任何内容：不回移 wtxid 中继或 taproot——让 taproot 等待 Bitcoin Core 0.21 发布后的某个时间，预计在 2020 年 12 月发布。

    尚未就选择哪一个选项达成明确结论。

  • ● Bitcoin Core #19473 添加了 networkactive 作为命令行启动和配置文件选项。设置此选项可以启用或禁用所有 P2P 网络活动。节点启动后，可以使用现有的 setnetworkactive RPC 或 GUI 中的网络活动按钮来切换网络活动。

  • ● Eclair #1485 添加了对使用与 LND（见 Newsletter #30）和 C-Lightning（见 Newsletter #94 和 #107）中先前实现的相同 keysend 协议的自发支付的支持。该合并的 PR 支持接收自发支付（标记为捐赠）和使用新的 sendWithPreimage 方法发送支付。

  • ● Eclair #1484 添加了对锚定输出承诺交易更改的低级支持。尚未添加的是更高级别的支持，使得 Eclair 能够与对等节点协商使用锚定输出，但这个早期步骤通过了所有建议的测试向量。

  • ● LND #4455 启用了基于 PSBT 的安全批量通道开启。之前，批次中的每次成功通道协商都会过早地广播包含所有通道资金输出的整个交易。这意味着后续的通道协商失败可能导致资金卡住。这个合并的 PR 引入了 openchannel 命令的 --no_publish 标志，该标志可用于延迟交易广播，直到批次中的最后一个通道。