本周的周报总结了有关扩展 BOLT11 发票以请求两个付款的讨论。还包括我们关于交易池子规则限定系列的另一个条目，以及我们的常规部分：描述了客户端和服务的更新、新版本和候选版本以及热门比特币基础设施软件的重大变更。

新闻

  • ● 将 BOLT11 发票扩展为请求两个付款的提案： Thomas Voegtlin 在 Lightning-Dev 邮件列表中发帖建议将 BOLT11 发票扩展到可选地允许接收者从付款者那里请求两个单独的付款，每个付款都有单独的秘密值和金额。Voegtlin Voegtlin 解释了这对潜水艇互换和即时 JIT通道都有用处：

    • ● 潜水艇互换是指支付链下的 LN 发票会导致在链上收到资金（潜水艇互换也可以反向操作，从链上到链下，但这里不讨论）。链上接收方选择一个秘密值，链下支付者向该秘密值的哈希支付一个 HTLC，该 HTLC 通过 LN 路由到潜水艇互换服务提供商。服务提供商收到该秘密值的链下 HTLC，并创建一个链上交易，支付给该 HTLC。当用户确认链上交易安全后，他们会揭示秘密值以结算链上 HTLC，并使服务提供商结算链下 HTLC（以及任何依赖于相同秘密值的 LN 上的转发付款）。

      然而，如果接收者不透露他们的秘密，那么服务提供商将不会收到任何补偿，并且需要花费他们刚刚创建的链上输出，而没有任何收益。为了防止这种滥用，现有的潜水艇互换服务要求花费者在服务创建链上交易之前使用 LN 支付费用（待链上 HTLC 结算成功，服务端可以选择退还部分或全部费用）。预付款和潜艇交换的金额不同，需要在不同的时间结算，因此需要使用不同的秘密。当前的 BOLT11 发票只能包含一个秘密值的承诺和一个金额，因此任何进行潜水艇互换的钱包目前需要编程以处理与服务器的交互，或者需要花费者和接收者共同完成多步工作流程。

    • ● 即时（JIT）通道，是指没有通道（或没有流动性）的用户与服务提供商创建虚拟通道；当第一笔付款到达该虚拟通道时，服务提供商创建一个区块链交易，既为通道提供资金，又包含该付款。与任何 LN HTLC 一样，链下支付是只有接收者（用户）知道秘密值。如果用户确信 JIT 通道注资交易是安全的，他们会披露秘密值以领取付款。

      然而，同样地，如果用户不披露他们的秘密值，那么服务提供商将不会收到任何补偿，并且将承担链上成本而无所获得。Voegtlin 认为，现有的 JIT 通道服务提供商通过要求用户在注资交易得到保障之前披露他们的秘密值来避免这个问题，他说这可能会产生法律问题，并阻止非托管钱包提供类似的服务。

    Voegtlin 建议允许 BOLT11 发票包含两个不同金额的秘密值承诺，一个用于预付费以支付链上交易成本，另一个用于实际的潜水艇互换或 JIT 通道资金。该提案收到了几个评论，我们将总结其中的一些：

    • ● 潜水艇互换需要专用逻辑： Olaoluwa Osuntokun 指出，潜水艇互换的接收方需要创建一个秘密值，分发它，然后在链上结算付款。最便宜的结算方式是与互换服务提供商互动。如果支出者和接收者无论如何都要与服务提供商互动，就像某些现有实现中经常出现的情况一样，其中支出者和接收者是同一个实体，他们不需要使用发票传达额外的信息。Voegtlin 回答说，一个专门的软件可以处理交互，从而消除在支付者链下钱包和接收者链上钱包中实现额外逻辑的需要，但这仅在 LN 钱包可以在同一发票中支付两个独立的秘密值和金额时才可能。

    • ● BOLT11 已经定型： Matt Corallo 回复说，目前还无法让所有闪电网络实现更新其 BOLT11 支持以支持不包含金额的发票(以允许自发付款)，因此他认为在此时添加额外字段是一种不切实际的方法。Bastien Teinturier 发表了类似的评论，建议改为在要约 offers中添加这类支持。Voegtlin 不同意，认为添加支持是可行的。

    • ● 通道拼接的替代方案： Corallo 还询问了：如果通道拼接技术可用，为什么还要修改协议以支持潜水艇互换呢？在该线程中没有提到，但是潜水艇互换和通道拼接都允许将链下资金移动到链上输出，但通道拼接在链上更有效，而且不会有手续费得不到补偿的问题。Voegtlin 回答说：潜水艇互换允许 LN 用户提高接收新的 LN 支付的容量，而通道拼接不行。

    在编写本报告时，讨论似乎仍在进行中。

等待确认 #6：规则一致性

这是一个关于交易转发、交易池纳入以及挖矿选择的限定周刊———解释了为什么 Bitcoin Core 设置了比共识规则更严格的交易池规则，以及钱包可以如何更高效地使用这些交易池规则。

上周的文章介绍了 “规则（policy）”，这是一组在共识规则之外应用的交易验证规则。这些规则不适用于已入块的交易，因此即使节点的规则与其对等节点不同，它仍然可以保持一致性。就像节点操作员可以决定不参与交易中继一样，他们也可以自由选择任何规则，甚至不选择任何规则（将其节点暴露于 DoS 风险之下）。这意味着我们不能假设整个网络的交易池规则完全相同。然而，为了让用户的交易被矿工接收，愿意接纳这笔交易到自己的交易池的节点必须形成一条通向矿工的路径——节点之间的规则差异直接影响交易中继功能。

作为节点规则差异的极端例子，想象一种情况，每个节点操作员选择一个随机的nVersion，并仅接受具有该nVersion的交易。由于大多数点对点关系具有不兼容的规则，交易将无法传播到矿工。

另一方面，网络中相同的规则有助于聚合交易池的内容。具有一致交易池的网络可以最顺畅地中继交易，并且也非常适合费用估算和致密区块中继，正如之前的帖子中所提到的。

考虑到交易池验证的复杂性和规则不一致带来的困难，Bitcoin Core 在规则可配置性方面一直保守。虽然用户可以轻松地调整 sigops 计数的方式(bytespersigop)以及嵌入在OP_RETURN输出中的数据量限制(datacarriersize和datacarrier)，但他们不能选择违背 400,000 个重量单位的最大标准重量，也不能应用别的一套与手续费相关的 RBF 规则，除非改变源代码。

Bitcoin Core 的一些规则配置选项存在是为了适应节点操作环境和运行节点的目的的差异。例如，矿工的硬件资源和保持交易池的目的与日常用户在笔记本电脑或树莓派上运行轻量级节点的目的不同。矿工可以选择增加他们的交易池容量(maxmempool)或过期时间线(mempoolexpiry)以在高峰期存储低费率交易，然后在流量减少时进行挖掘。提供可视化、存档和网络统计的网站可能运行多个节点，以收集尽可能多的数据，并显示默认的交易池行为。

在单个节点上，交易池容量的选择会影响费用提升工具的可用性。当交易池最低费率因交易提交超过默认交易池大小而上升时，从交易池的“底部”清除的交易和低于此费率的新交易不能再使用 CPFP进行 费用提升。

另一方面，由于被清除的交易所用的输入不再为交易池中的任何交易所用，此前无法进行的 RBF 手续费追加也许又变成可能了。新交易实际上并没有替换这个节点的交易池中的任何内容，因此不需要考虑通常的 RBF 规则。但是，（因为具有更大的交易池容量而）没有逐出原版交易的节点将新交易视为拟议的替换，并要求其遵守 RBF 规则。如果被清除的交易没有发出 BIP125 可替换信号，或者新交易的费用即使费率很高但不符合 RBF 要求，矿工可能收不到他们的新交易。钱包必须小心处理被清除的交易：交易的输出不能被视为可以花费，但输入同样不能被重复使用。

乍一看，具有更大的交易池容量的节点似乎使 CPFP 更有用、使 RBF 更无用。然而，交易中继受紧急的网络行为的影响，可能不存在接受用户 CPFP 并将其转发到矿工的节点路径。节点通常只在接受交易并将其放入交易池后转发一次，并忽略已存在于其交易池中的交易的通知——存储更多交易的节点在这些交易被重新广播到它们时充当黑洞。除非整个网络增加其交易池容量（这将是更改默认值的迹象），否则用户不应该指望从增加自己的交易池容量中获得太多好处。交易池默认设置的最低费率限制了在高流量时使用 CPFP 的效用。成功地将 CPFP 交易提交到自己增大了的交易池的用户可能无法注意到该交易未传播给其他人。

交易中继网络由动态加入和离开网络的个体节点组成，每个节点必须保护自己不被爆破。因此，交易中继只能尽力而为，我们不能保证每个节点都了解每个未确认的交易。同时，如果节点收敛在一组使得交易池尽可能同质化的中继规则上，那么比特币网络的表现就会最佳。下一篇文章将探讨采取了哪些规则来符合整个网络的利益。

服务和客户端软件变更

在这个月度栏目中，我们会标出比特币钱包和服务的有趣更新。

  • ● Greenlight 库开源： 非托管 CLN 节点服务提供商 Greenlight 宣布推出包含客户端库和语言绑定库的repository，以及测试框架指南.

  • ● Tapscript 调试器 Tapsim： Tapsim 是一个脚本执行调试(见 周报 #254)和使用 btcd 的 tapscript 可视化工具。

  • ● Bitcoin Keeper 1.0.4 发布: Bitcoin Keeper 是一款支持多重签名、硬件签名、BIP85的移动钱包，最新版本还支持使用 Whirlpool 协议的coinjoin。

  • ● 闪电钱包 EttaWallet 宣布： 移动端钱包 EttaWallet 最近发布。其闪电钱包特性来自于 LDK，而其对可用性的强烈偏重则受到了 Bitcoin Design Community 的日常消费钱包参考设计的启发。

  • ● 基于 zkSNARK 的区块头同步 PoC 宣布： BTC Warp 是一个轻客户端同步 proof-of-concept，使用 zkSNARK 来证明和验证比特币区块头。一篇博客文章提供了详细的方法。

  • ● lnprototest v0.0.4 释放： lnprototest 项目是一个测试套件，用于测试LN，包括“一组用 Python3 编写的测试助手，旨在使您在提出闪电网络协议更改建议（以及测试现有实现）时编写新测试变得容易。

版本和候选版本

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

  • ● Eclair v0.9.0 是这个 LN 实现的新版本，其中包含了许多为重要（且复杂）闪电网络特性做准备的工作：双向注资， 通道拼接和BOLT12 要约。这些特性目前还处于实验阶段。此版本还“使插件更加强大，引入了各种类型 DoS 的缓解措施，并在代码库的许多领域提高了性能”。

重大的代码和文档变更

本周的重大变更有 Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals (BIPs)、Lightning BOLTs 和 Bitcoin Inquisition。