本周的周报包括提议的 OP_VAULT 操作码的 BIP 草案的链接，总结了关于允许闪电网络节点在其通道上设置服务质量标志的讨论，转发了对闪电网络邻居节点评估标准反馈的请求，并描述了一个为种子备份和恢复方案 BIP 草案，可以在没有电子设备的情况下可靠地执行。此外还包括我们的常规部分，其中包含 Bitcoin StackExchange 中热门问答的摘要、新版本和候选版本的公告，以及对流行的比特币基础设施软件的显著变化的描述。

新闻

  • ● OP_VAULT 的 BIP 草案： James O’Beirne 在 Bitcoin-Dev 邮件列表中发布了一个指向他之前提出的 OP_VAULT 操作码的 BIP 草案的链接（参见 Newsletter #234）。他还宣布，他将尝试将代码合并到 Bitcoin Inquisition 中，该项目用于测试对比特币共识和网络协议规则的大的提议变更。

  • ● 闪电网络服务质量标志：Joost Jager 在 Lightning-Dev 邮件列表中发布了一项允许节点发出通道“高度可用”信号的提案，表明其运营商相信它能够无故障地转发付款。如果它确实未能转发付款，则支付者可能会选择在很长一段时间内不使用该节点进行未来的付款——这比付款人可能使用没有宣传高可用性的节点的时间长很多。想最快完成支付（而不是低费用）的支付者会优先选择由自认高可用节点组成的支付路径。

    Christian Decker 的回复对信誉系统中的问题进行了出色的总结，包括自认信誉的案例。他担心的一个问题是，一般的支付者不会向任何足够近的地方发送付款，以在大型网络的支付通道中频繁遇到相同的节点。如果重复的业务无论如何都很少，那么暂时不提供重复业务的威胁可能就不会有效。

    Antoine Riard 提醒 参与者关于加速支付的一种替代方法——带恢复的超额支付。以前被描述为回旋镖支付（参见Newsletter #86）和可退款的超额支付（参见Newsletter #192），支付者会将他们的付款金额加上一些额外的钱，将其分成几个部分并通过各种路线来发送。当到达的部分足以支付发票费用时，收款人就收下这些部分，并拒绝之后到达的任何额外部分（与额外资金）。这要求想要快速支付的支付者在他们的通道中有一些额外的资金，即使支付者选择的某些路径失败，它也能起作用。这降低了对支付者要能容易地找到高度可用通道的要求。这种方法的挑战是要建立一种机制，防止接收者保留任何到达的多支付的款项。

  • ● 对闪电网络良好邻居评分的请求反馈：Carla Kirk-Cohen 和 Clara Shikhelman 在 Lightning-Dev 邮件列表中发布，请求节点对推荐参数进行反馈，这些参数用于判断其通道对手方是否是一个转发付款的良好来源。他们提出了几个判断标准，并为每个标准推荐了默认参数，但正在寻求对所做选择的反馈。

    如果一个节点确定它的一个相连节点是一个好邻居，并且该邻居将转发的支付标记为由它背书，则该节点可以为该支付提供比它提供不合格支付更多的资源访问权限。节点也可以在将支付转发到下一个通道时背书支付。正如 Shikhelman 之前与人合著的一篇论文中所述（参见 Newsletter #226），这是减轻通道阻塞攻击提案的一部分。

  • ● 为 Codex32 种子编码方案提议的 BIP：Russell O’Connor 和 Andrew Poelstra（使用他们名字的变位词）提出一个新的用于备份和恢复 BIP32 种子方案的 BIP。类似于 SLIP39，它可以选择允许使用 Shamir 的秘密共享方案（SSSS）创建多个分片，要求一起使用可配置数量的分片来恢复种子。获得少于阈值份额的攻击者将对种子一无所知。与使用词表的 BIP39、Electrum、Aezeed 和 SLIP39 恢复代码不同，Codex32 使用与 bech32 地址相同的字母表。BIP 草案中的一个示例：

      ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm

    Codex32 相对于所有现有方案的主要优势在于，所有操作都可以仅使用笔、纸、说明书和剪纸来执行。这包括生成编码种子（此处可以使用骰子）、使用校验和保护种子、生成校验和共享、验证校验和以及恢复种子。我们发现能够手动验证种子或分片备份的校验和的想法是一个特别有力的概念。用户验证单个种子备份的唯一当前方法是将其输入可信计算设备并查看它是否导出预期的公钥——但确定该设备是否可信的过程通常并不简单。更糟糕的是，为了验证现有 SSSS 分片的完整性（例如在 SLIP39 中），用户必须将他们想要验证的每个分片与足够多的其他分片放在一起以达到阈值，然后将它们输入可信计算设备。这意味着验证分片完整性首先否定了拥有分片的一大好处——通过将信息分发到多个地方或多个人来保证信息安全的能力。借助 Codex32，用户可以仅使用纸、笔、一些印刷材料和几分钟的时间，定期单独验证每个分片的完整性。

    邮件列表上的讨论主要集中在 Codex32 和 SLIP39 之间的差异上，后者已经在生产中使用了几年。我们建议任何对 Codex32 感兴趣的人研究其网站或观看其作者的视频。通过 BIP 草案，提案作者希望看到钱包开始增加对使用 Codex32 编码种子的支持。

Bitcoin Stack Exchange 网站的精选问答

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

版本和候选版本

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

  • ● BDK 0.27.1 是一个安全更新，用于修复“有时 […] 在将大字符串输入进 SQLite 的 printf 函数时导致数组边界溢出”的漏洞。只有使用 BDK 的可选 SQLite 数据库功能的软件才需要更新。有关更多详细信息，请参阅漏洞报告。

  • ● Core Lightning 23.02rc3 是这个流行的闪电网络实现的新维护版本的候选发布版本。

重大的文档和代码变更

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

  • ● Bitcoin Core #24149 添加了对基于 P2WSH 基于 miniscript 的 输出描述符的签名支持。如果所有必要的原像和密钥都可用并且符合时间锁，Bitcoin Core 将能够签署任何 miniscript 描述符输入。 Bitcoin Core 钱包中仍然缺少完整的 Miniscript 支持的一些功能：钱包在签名之前无法估计某些描述符的输入权重，并且在某些边界案例下还无法签署 PSBTs。对 P2TR 输出的 Miniscript 支持也仍在等待中。

  • ● Bitcoin Core #25344 更新了 bumpfee 和 psbtbumpfee 以创建手续费替换（RBF）的手续费追加。该更新允许为替换交易指定输出。替换可能包含与被替换交易不同的一组输出。这可用于添加新输出（例如，用于迭代支付批处理）或删除输出（例如，用于尝试取消未确认的支付）。

  • ● Eclair #2596 限制节点尝试打开双方充值 通道的次数 RBF，可以在节点不接受任何尝试更新前，给打开通道交易追加费用。这是因为节点需要存储有关打开通道的交易的所有可能版本的数据，所以允许无限制的费用追加可能会有问题。通常情况下，在实践中，可以产生的费用追加的数量是由每次替换所需要支付的额外交易费用限制的。然而，双方充值协议预期一个节点要存储它无法完全验证的那些费用追加，这意味着攻击者可以创建无限数量的无效费用追加交易，这些交易永远不会确认也不会付出任何交易手续费。

  • ● Eclair #2595 继续该项目在添加通道拼接支持上的工作，更新了在这种情况下用于构建交易的函数。

  • ● Eclair #2479 在以下流程中添加了对支付要约 的支持：用户收到要约，告诉 Eclair 付款；Eclair 使用要约从接收方获取发票，验证发票包含所预期的参数，并根据该发票进行支付。

  • ● LND #5988 添加了一个新的可选概率估计器来寻找支付路径。它一部分上是基于之前的寻路研究（参见 Newsletter #192），也参考了其他方法。

  • ● Rust Bitcoin #1636 添加了一个 predict_weight() 函数。函数的输入是交易构建的模板；输出是交易的预期权重。这对于费用管理特别有用：要确定需要将哪些输入添加到交易中，需要知道费用金额，但要确定费用金额，需要知道交易的规模。该函数可以提供合理的大小估计，而无需实际构建候选交易。