本周的周报介绍了一种用于简化闪电通道合作式关闭的通信的协议，还总结了来自最近一期闪电网络开发者会议的笔记。此外是我们的常规栏目：Bitcoin Stack Exchange 上的热门问题和回答，新版本和候选版本的公告，以及热门比特币基础设施项目的重大变更的介绍。

新闻

  • ● 简化的闪电通道关闭协议：Rusty Russell 在 Lightning-Dev 邮件组中发帖，提出了一种可以简化两个闪电节点合作关闭通道的流程的提议。在这种新的关闭协议中，其中一个节点告知对手自己想关闭通道，并说明自己愿意支付的手续费金额。这个关闭操作的发起人将负责支付全部手续费，但在标准的合作关闭通道交易中，双方的输出都是立即可以花费的，所以每一方都可以在常规情况下使用 “子为父偿（CPFP）” 来追加手续费。这套新的协议也兼容于在基于 MuSig2 的 “无脚本式多签名合约” 中交换信息，后者是闪电网络正在开发的升级的一部分，可以提高隐私性并降低链上手续费开销。

    截至本刊撰写的时间，还没有人评论 Russell 的提议，但一些初步评论出现在他带有完整提议的 pull request 上。

  • ● 闪电峰会笔记：Carla Kirk-Cohen 在 Lightning-Dev 邮件组中发帖，总结了闪电网络开发者在纽约的最新一次会议的多项讨论。一些主题如下：

    • ● 可靠的交易确认：“交易包转发”、“v3 交易转发”、“临时锚点”、“集群交易池”，以及其它跟交易转发和挖矿有关的提议，都在会上得到了讨论：它们如何能提供更清晰的路径、让闪电网络的链上交易能更可靠地确认，而不会受到 “交易钉死攻击” 的威胁、在使用 CPFP 和 “手续费替换（RBF）” 时也不需要过度支付手续费？我们强烈建议对交易转发策略 —— 它会影响几乎所有的二层协议 —— 有兴趣的读者阅读这份笔记，了解闪电网络开发者对这些倡议提出的富有启发的反馈。

    • ● Taproot 和 Musig2 通道：简短讨论了使用 P2TR 输出和 MuSig2 签名的通道的开发进度。关于这次讨论的笔记的一个重大部分是关于一种简化的合作式关闭协议的；见上一条新闻，了解这次讨论的结果之一。

    • ● 升级的通道公告：当前的闪电网络 gossip 协议只转发使用一个 P2WSH 输出、承诺了一个 2-of-2 OP_CHECKMULTISIG 脚本的通道的创建和更新公告。若要迁移到使用基于 MuSig2 的无脚本式多签名合约承诺的 P2TR 输出，gossip 协议就需要相应升级。在闪电网络开发者的上一次面对面会议期间，另一个被讨论的话题（见周报 #204）是：仅对协议作最小量的升级（叫做 “v1.5 gossip”）、仅添加对 P2TR 的支持，还是对协议作更通用的升级（“v2.0”）、允许任何类型的 UTXO 的一个有效签名用在公告中。允许使用任何输出，意味着用在通道公告中的输出（相比当前）更有可能不是用来操作通道的输出，从而打破输出与通道注资交易之间的公开关联。

    人们讨论的一个额外的顾虑是，一个价值为 n 的 UTXO 是否允许用来宣布容量大于 n 的通道。如果可以，通道参与者可以让自己的一些注资交易保持私密。举个例子，Alice 和 Bob 可以开启两条独立的通道；他们可以使用其中一个通道输出来公告一条容量大于该输出的价值的通道、表明自己可以使用无法跟该输出关联起来的其它通道、路由比该输出价值更大的闪电支付，所以可以更加隐私。这可以帮助提高模糊性：网络中的任何输出，甚至是从未在闪电网络中 gossip 过的输出，都可以用在一条闪电通道中。

    • ● PTLC 和超额支付：从笔记来看，会议简要讨论了协议对 “点时间锁合约（PTLCs）” 的支持，讨论主要跟 “超额支付（适配器签名）” 有关。笔记的更多篇幅分配给了可能影响协议的类似部分的一项改进：redundantly overpay一张发票、并从大部分甚至全部超额部分中获得回款的能力。举个例子，Alice 希望最终给 Bob 支付 1 BTC。她一开始给 Bob 发送了 20 个 “多路径支付”、每个都价值 0.1 BTC 。使用数学（通过一种叫做 “Boomerang” 的技术，详见周报 #86）或者 “分层承诺（layered commitments）” 或者额外的沟通轮次（叫做 “Spear”），Bob 只能领取最多 10 笔支付；任何到达他的节点的多余支付都会被拒绝。这种方法的好处是，最多可以允许 10 笔多路径支付的碎片不送达 Bob 的节点，但依然不会推迟支付。缺点则是额外的复杂性，以及，在所有碎片都到达 Bob 的节点的情况下，可能降低支付速度（使用 Spear 时；相比于当前）。参与者们讨论了是否存在某些变更，既是 PTLC 所需的，又能帮助支持超额支付。

    • ● 通道阻塞攻击的缓解提议：笔记相当大一部分篇幅总结了关于缓解 “通道阻塞攻击” 的提议的讨论。讨论的起点是，有人声称已知的解决方案（比如声誉机制和预付费）中，没有哪一种仅凭自身就能令人满意地解决这个问题并且没有不可接受的缺点。声誉机制必须考虑到没有声誉的新节点，以及 HTLC 的自然失败几率 —— 攻击者可以利用这些规定造成某种程度的伤害，即使伤害程度比当前可造成的要轻。预付手续费必须设置得足够高，以阻遏攻击者，但这样可能也会阻遏诚实得用户，并产生一种不正当的激励机制，让节点故意不转发支付。然后，有人提出综合多种机制也许能获得一些好处，而不至于陷入最糟糕的情形中。

    在测试了对这些机制的理解之后，笔记集中于对周报 #226 所述的本地声誉机制的测试的细节，并为一种后续实现、与之搭配的低预付费机制奠定了基础。从笔记来看，似乎参与者们都支持测试这些提议。

    • ● 简化的承诺：参与者们讨论了简化的承诺协议的想法（详见周报 #120），该协议定义了哪一个节点应该向对手提议承诺交易的下一次变更，而不是允许任何一方随时提议一笔新的承诺交易。让其中一个通道参与者来主导，消除了双方几乎同时发送两个提议的复杂性，比如 Alice 和 Bob 同时希望给承诺交易增加 HTLC 输出的情况。笔记讨论了一个特殊的复杂问题：其中一方不想接受另一方的提议的情形，这在当前的协议中是复杂难解的情形。简化承诺方法的一个缺点是它可能会增加某些情况下的时延，比如当前不负责提议变更的一方需要向对手请求提议的特权，然后才能发出提议。笔记并没有表明讨论中出现了清楚的解决。

    • ● 形成规范的流程：参与者们还讨论了关于优化形成规范的流程及其管理的文档（比如当前的 BOLT 和 BLIP 以及其它已经成文的提议）的多种想法。讨论似乎非常发散，从笔记中看没有明确的结论。

Bitcoin Stack Exchange 的精选问答

Bitcoin Stack Exchange 是 Optech 的贡献者们寻找答案的首选之地，也是它们有闲暇时会给好奇和困惑的用户帮忙的地方。在这个月度栏目中，我们会列举自上次出刊以来出现的一些高票的问题和答案。

新版本和候选版本

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

  • ● HWI 2.3.0 是这个让软件钱包可以跟硬件签名设备沟通的中间件的新版本。它添加了对 DIY 的 Jade 设备的支持以及一个二进制文件，可以在安装了 MacOS 12.0+ 的 Apple Silicon 硬件上运行 hwi 主程序。

  • ● LDK 0.0.116 是这个用于创建闪电网络赋能的应用的库的新版本。它包含了对 “锚点输出” 和使用 keysend 的 多路径支付 的支持。

重大的代码和文档变更

本周出现重大变更的有：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。

  • ● Bitcoin Core GUI #740 升级了 PSBT 操作对话，以将给你自己的钱包支付的输出标记为 “你自己的地址”。这简化了对导入的 PSBT 的结果的评估，尤其是将找零返回给发送者的交易。