本周的 Newsletter 提供了新的 MuSig2 论文概述，汇总了关于 LN 预付费的进一步讨论，并描述了一个简化 LN 支付管理的提案。此外，还包括常规部分：客户端和服务的显著改进总结、发布与候选发布的公告，以及对流行比特币基础设施软件的更改。

行动项

本周无。

新闻

  • ● MuSig2 论文发布： Jonas Nick、Tim Ruffing 和 Yannick Seurin 发布了 MuSig2 论文，描述了一种新的 MuSig 签名方案变体，该方案采用了两轮签名协议。

    MuSig 是一种签名方案，允许多个签名者通过各自的私钥创建一个聚合公钥，然后协作生成该公钥的单一有效签名。聚合公钥和签名与任何其他 Schnorr 公钥和签名在外观上是无法区分的。

    MuSig 的原始版本需要三轮签名协议：首先，共签名者交换 nonce 值的承诺，然后交换 nonce 值，最后交换部分签名。没有这三轮协议，攻击者可能会在多个并发签名会话中与诚实的签名者交互，获取该诚实签名者不愿签署的消息的签名。

    使用确定性 nonce 在单一签名方案中很常见，但在多签名方案中是不安全的，正如原始 MuSig 博客文章中描述的那样。提前预计算 nonce 并在密钥设置时交换它们也是不安全的，正如 Jonas Nick 的博客文章中所述。然而，将 nonce 提前计算并在早期交换 nonce 承诺是安全的，这将三轮中的一轮移到密钥设置阶段。

    移除交换 nonce 承诺的要求一直是一个活跃的研究领域，上个月发布的 MuSig-DN 论文展示了如何通过使用签名者的公钥和消息来确定性地生成 nonce 并提供一个非交互式零知识证明，从而移除 nonce 承诺交换的需求，代价是签名操作的成本增加。

    新的 MuSig2 方案实现了无需零知识证明的简单两轮签名协议。更重要的是，第一轮（nonce 交换）可以在密钥设置时完成，从而支持以下两种变体：

    • 交互式设置（密钥设置和 nonce 交换）和非交互式签名

    • 非交互式设置（从公钥计算地址）和交互式签名（nonce 交换后交换部分签名）

    非交互式签名变体对冷存储方案和离线签名者特别有用，也对 LN 等离链合同协议有帮助，nonce 可以在通道设置时交换。

  • ● LN 预付费讨论更新： 在上周的讨论之后，Joost Jager 在 Lightning-Dev 邮件列表中要求开发者再次考虑如何收取路由支付尝试的费用——即使尝试失败也要支付的费用。这可能有助于缓解阻止节点赚取路由费的“阻塞攻击”和允许第三方追踪他人通道余额的“探测攻击”。不幸的是，开发者尚未找到无需信任的方式来收取预付费用，因此近期的讨论集中在可能涉及微小费用的信任基础方法上，希望用户可以接受这些小额费用。

    不幸的是，本周讨论的所有方法似乎都未能获得广泛认可。几位开发者表达了对方法可能被滥用以惩罚小型诚实节点的担忧。其他开发者指出，预付费的替代方案是依赖声誉系统——这可能会不成比例地使大型节点受益。我们相信开发者将继续研究这一重要问题，并将在未来的 Newsletter 中报告任何值得注意的进展。

  • ● 简化 HTLC 协商： Rusty Russell 在 Lightning-Dev 邮件列表中发布有关简化 LN 通道中支付创建和解决的提案。目前，通道双方都可以提议转发或结算支付，这需要在离链承诺交易中创建或移除一个 HTLC。有时双方会同时提议更改，从而出现冲突的承诺交易。如果允许对承诺交易格式和设置进行动态更改（参见 Newsletter #108），这些潜在冲突可能会变得更加复杂。一种消除该复杂性的提案是仅在所有 HTLC 已解决并通道处于空闲状态时才允许动态更改——这提高了安全性，但限制性较大。

    Russell 本周提出的提案是仅允许通道中的一方提出 HTLC 更改。这消除了冲突提案的风险，但将平均网络通信开销增加了半个往返（假设每方提出的 HTLC 更改次数相等）。提出更改的责任可以根据需要从一方转移到另一方，允许各方在不同时间提出通道更新。

    截至撰写本文时，该提案仅收到少量来自其他 LN 实现维护者的讨论，因此其未来尚不确定。

服务和客户端软件的更改

在本月的特刊中，我们重点介绍了比特币钱包和服务的有趣更新。

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

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

  • ● Bitcoin Core #19953 实现了 Schnorr 签名验证（BIP340）、Taproot 验证（BIP341）和 Tapscript 验证（BIP342）。新的软分叉规则目前仅在私有测试模式（”regtest”）下使用；它们尚未在主网、测试网或默认 signet 上执行。计划在 Bitcoin Core 0.21.0 中发布代码，然后准备后续版本（例如 0.21.1），当检测到激活信号时即可开始执行软分叉的新规则。使用何种特定的激活信号仍在 ##taproot-activation IRC 聊天室中讨论（日志）。

    该代码包含大约 700 行与共识相关的更改（500 行除去注释和空白）和 2,100 行的测试。超过 30 人直接审查了此 PR 及其前身，许多人参与了相关研究、BIPs、libsecp256k1 的相关代码以及系统其他部分的开发和审查。虽然仍有更多工作要做，但代码的正确审查可以说是最关键的一步——因此，我们向所有帮助实现这一里程碑的人致以最深切的感谢。

  • ● Bitcoin Core #19988 重新设计了 Bitcoin Core 请求其节点对等方的交易逻辑。PR 描述的主要更改包括：Bitcoin Core 现在更倾向于请求来自出站对等方的交易，即由本地节点打开连接的对等方；Bitcoin Core 现在将请求无限数量的交易，而不是在 100 笔交易后停止（尽管响应较慢的对等方不会被优先考虑）；Bitcoin Core 不会像之前那样跟踪大量未决的交易请求，因为之前的限制被认为过多。此更改还大大提高了代码的可读性和测试交易请求逻辑按预期工作的能力。此测试可能有助于减少漏洞被用于时间敏感交易（如 LN 和许多其他合同协议）用户的风险。

  • ● Bitcoin Core #19077 为钱包记录添加了一个新的 SQLite 数据库后端。与现有的 Berkeley DB 数据库后端不同，SQLite 旨在并经过测试能够抗击崩溃和断电带来的损坏。在即将发布的 v0.21 版本中，旧版钱包将继续使用 Berkeley DB 后端，而新引入的描述符钱包将默认使用此新的 SQLite 后端。正在 Bitcoin Core #20160 中讨论开发迁移路径和弃用旧版钱包及 Berkeley DB 钱包后端的初步时间表。

  • ● Bitcoin Core #19770 废弃了 getpeerinfo RPC 返回的 whitelisted 字段，该字段以前因更细粒度的权限而扩展（参见 Newsletter #60）。whitelisted 计划在 v0.21 中弃用并在 v0.22 中删除。

  • ● Bitcoin Core #17428 在关闭时写入一个文件，记录节点的两个仅区块中继的出站对等方的网络地址。节点下一次启动时，会读取此文件并尝试重新连接到相同的两个对等方。这可以防止攻击者利用节点重启触发对等方的完全更换，这可能会被用于 eclipse 攻击，该攻击可能会欺骗节点接受无效的比特币。

  • ● LND #4688 添加了一个新的 --duration 参数，可用于指示 LND 何时停止进一步的支付尝试。默认值仍为 60 秒。

  • ● Libsecp256k1 #830 启用 GLV 端同态，这允许在验证签名时最多减少 33% 的操作（请参阅 PR 中的实际性能测试结果）。该 PR 还移除了无端同态操作的较慢代码，因为 GLV 技术的专利已过期（见 Newsletter #117）。该 PR 还实现了独立的 memcmp（内存比较）函数，以避免使用 GCC 内部版本带来的问题（见 Newsletter #117 的另一节）。这些更改随后被拉取到 Bitcoin Core 中。