本周的周报链接了一个比特币的 secp256k1 曲线的椭圆曲线密码学的教育实现。此外还包括我们的常规部分：描述了关于共识更改的讨论、新版本和候选版本的公告，以及对热门比特币基础设施项目的重大变更介绍。

新闻

  • ● 教育和实验性的 secp256k1 实现： Sebastian Falbesoner、Jonas Nick 和 Tim Ruffing 在 Bitcoin-Dev 邮件列表上发布了一个与比特币中使用的密码学相关的各种函数的 Python 实现。他们警告说，该实现是“不安全的”（原文大写）并且“旨在用于原型设计、实验和教育”。

    他们还指出，几个 BIP（340、324、327 和 352）的参考和测试代码已经包含了“自定义且有时微妙不同的 secp256k1 实现”。他们希望未来能改进这种情况，可能从即将推出的 ChillDKG 的 BIP 开始（见周报 #312）。

共识更改

在这个月度部分，我们总结了关于更改比特币共识规则的提案和讨论。

  • ● 关于量子计算机盗窃和抵抗的多项讨论： 几场对话探讨了比特币人如何应对量子计算机强大到足以盗取比特币的情况。

    • ● 应该销毁易受攻击的比特币吗？ Jameson Lopp 在 Bitcoin-Dev 邮件列表上发布了几个支持在采用抗量子升级路径并且用户有时间采用解决方案后销毁易受量子盗窃的比特币的论点。一些论点包括：

      • ● 基于共同偏好的论点： 他认为大多数人会更愿意他们的资金被销毁而不是被拥有快速量子计算机的人盗取。特别是，他认为，因为小偷将是“少数几个能够早期获得量子计算机的特权人士”。

      • ● 基于共同伤害的论点： 许多被盗的比特币要么是丢失的币，要么是计划长期持有的币。相比之下，小偷可能会迅速花费他们盗取的比特币，这会降低其他比特币的购买力（类似于货币供应通胀）。他指出，比特币购买力的降低会减少矿工收入，降低网络安全性，并（根据他的观察）导致商家接受比特币的意愿降低。

      • ● 基于最小收益的论点： 虽然允许盗窃可能会用于资助量子计算的发展，但盗取币并不为比特币协议的诚实参与者提供任何直接利益。

      • ● 基于明确截止日期的论点： 没有人能够提前很久知道某人拥有量子计算机可以开始盗取比特币的日期，但可以提前很久以完美的精确度宣布易受量子攻击的币将被销毁的特定日期。这个明确的截止日期将为用户提供更多激励，以确保及时重新保护他们的比特币，确保更少的总币量损失。

      • ● 基于矿工激励的论点： 如上所述，量子盗窃可能会减少矿工收入。持续多数的算力可以审查易受量子攻击的比特币的支出，即使其他比特币用户更喜欢不同的结果，他们也可能这样做。

      Lopp 还提供了几个反对销毁易受攻击的比特币的论点，但他的结论支持销毁。

      Nagaev Boris 询问是否超过升级截止日期的时间锁定的 UTXO 也应该被销毁。Lopp 指出了长时间锁定的现有陷阱，并表示他个人对“锁定资金超过一两年感到有点紧张”。

    • ● **通过揭示 SHA256 原象安全地证明 UTXO 所有权： Martin Habovštiak 在 Bitcoin-Dev 邮件列表上发布了一个想法，即使 ECDSA 和schnorr 签名不安全（例如，在快速量子计算机存在之后），也可以允许某人证明他们控制了一个 UTXO。如果 UTXO 包含一个 SHA256 承诺（或其他抗量子承诺）到一个以前从未被揭示的原象，那么揭示该原象的多步协议可以与共识更改相结合，以防止量子盗窃。这在本质上与 Tim Ruffing 的先前的提案相同（见周报 #141），他了解到这通常被称为 Guy Fawkes 签名方案。它也是 Adam Back 在 2013 年发明的一个方案的变体，旨在提高对矿工审查的抵抗力。简而言之，该协议可以这样工作：

      1. Alice 接收到一个以某种方式进行 SHA256 承诺的输出的资金。这可以是直接哈希输出，如 P2PKH、P2SH、P2WPKH 或 P2WSH，或者是带有脚本路径的 P2TR 输出。

      2. 如果 Alice 收到多笔支付到同一输出脚本，她必须要么在准备好花费所有这些资金之前不花费任何一笔（对于 P2PKH 和 P2WPKH 肯定需要；对于 P2SH 和 P2WSH 可能也实际上需要），要么非常小心地确保通过她的花费至少有一个原象保持未揭示（使用 P2TR 密钥路径与脚本路径花费很容易实现）。

      3. 当 Alice 准备好花费时，她私下正常创建她的花费交易但不广播它。她还获取一些由量子安全签名算法保护的比特币，以便支付交易费用。

      4. 在花费一些“量子安全”的比特币的交易中，她承诺到要花费的“量子不安全”比特币，并且还承诺到私人花费交易（不揭示它）。她等待这个交易被深度确认。

      5. 在她确信她之前的交易实际上不能被重组后，她揭示她先前私人的原象和“量子不安全”比特币的花费。

      6. 网络上的节点搜索区块链以找到第一个承诺到该原象的交易。如果该交易承诺到 Alice 的“量子不安全”的花费，那么他们执行她的花费。否则，他们什么也不做。

      这确保了 Alice 不必揭示易受量子攻击的信息，直到她已经确保她的花费交易版本将优先于量子计算机操作者的任何尝试花费。有关协议的更精确描述，请参阅 Ruffing 的 2018 年帖子。虽然在帖子中没有讨论，但我们相信上述协议可以作为软分叉部署。

      Habovštiak 认为，可以使用此协议安全花费的比特币（例如，其原象尚未被揭示）不应该被销毁，即使社区决定要销毁一般的易受量子攻击的比特币。他还认为，在紧急情况下安全花费一些比特币的能力减少了短期内部署量子抵抗方案的紧迫性。

      Lloyd Fournier 表示，“如果这种方法获得接受，我认为用户可以采取的主要立即行动是转向 taproot 钱包”，因为它能够在当前共识规则下允许密钥路径花费，包括在地址复用的情况下，但如果密钥路径花费后来被禁用，也能抵抗量子盗窃。

      在另一个主题中（见下一项），Pieter Wuille 指出，易受量子盗窃的 UTXO 还包括那些尚未公开使用但为多方所知的密钥，例如在各种形式的多重签名中（包括 LN、DLC 和托管服务）。

    • ● **销毁“量子不安全”比特币的 BIP 草案： Agustin Cruz 在 Bitcoin-Dev 邮件列表上发布了一个BIP 草案，描述了销毁易受量子盗窃的比特币的一般过程的几个选项（如果这成为预期风险）。Cruz 认为，“通过强制执行迁移截止日期，我们为合法所有者提供了一个明确、不可协商的机会来保护他们的资金 […] 强制迁移，在充分通知和强大保障的情况下，对保护比特币的长期安全既现实又必要。”

      主题的讨论很少关注 BIP 草案。大多数讨论集中在销毁量子易受攻击的比特币是否是一个好主意上，类似于后来由 Jameson Lopp 开始的主题（在前一个子项中描述）。

  • ● 关于 CTV+CSFS 软分叉的多项讨论： 几场对话检验了软分叉引入 OP_CHECKTEMPLATEVERIFY（CTV）和 OP_CHECKSIGFROMSTACK（CSFS）操作码的各个方面。

    • ● **对 CTV 动机的批评： Anthony Towns 发布了对 BIP119 描述的 CTV 动机的批评，他认为这个动机会被同时向比特币添加 CTV 和 CSFS 所削弱。在讨论开始几天后，BIP119 的作者更新了 BIP119，删除了大部分（可能是全部）有争议的语言；请参阅周报 #347中我们对这一变更的总结，以及 BIP119 的旧版本作为参考。讨论的一些主题包括：

      • ● *CTV+CSFS 允许创建永久限制条款：* CTV 的动机说，”限制条款历来被广泛认为不适合比特币，因为它们实现起来太复杂，并且有可能降低受限制条款约束的币的同质化。这个 BIP 引入了一个称为模板的简单限制条款，它能够实现一组有限的高价值用例，而没有显著风险。BIP119 模板允许非递归**完全枚举的限制条款，没有动态状态”（原文强调）。

        Towns 描述了一个同时使用 CTV 和 CSFS 的脚本，并链接到 MutinyNet signet 上使用它的一个交易，该交易只能通过将相同数量的资金发送回脚本本身来花费。虽然对定义有一些争论，但 CTV 的作者之前描述了一个功能上相同的结构为递归限制条款，Optech 在其对该对话的总结中遵循了这一惯例（参见周报 #190）。

        Olaoluwa Osuntokun 为 CTV 的动机辩护，认为使用它的脚本仍然是“完全枚举的”和“没有动态状态”的。这似乎类似于 CTV 的作者（Jeremy Rubin）在 2022 年提出的一个论点，他称 Towns 设计的自我支付限制条款类型为“递归但完全枚举”。Towns 反驳说，添加 CSFS 削弱了完全枚举的声称好处。他要求 CTV 或 CSFS 的 BIP 更新，以描述“那些既可怕又仍然被 CTV 和 CSFS 的组合所阻止的用例”。这可能已经在 BIP119 的最近更新中完成，其中描述了一个“自我复制的自动机（俗称 SpookChains）”，这在使用 SIGHASH_ANYPREVOUT 时是可能的，但在使用 CTV+CSFS 时是不可能的。

      • ● **CTV 和 CSFS 的工具： Towns 指出，他发现使用现有工具开发上述递归脚本很困难，表明部署准备不足。Osuntokun 表示他使用的工具“相当直接”。Towns 和 Osuntokun 都没有提到他们使用了什么工具。Nadav Ivgi 提供了一个使用他的 Minsc 语言的例子，并表示他“一直在努力改进 Minsc，使这类事情更容易。它支持 Taproot、CTV、PSBT、描述符、Miniscript、原始脚本、BIP32 等”。尽管他承认“其中很多仍未形成文档”。

      • ● **替代方案： Towns 将 CTV+CSFS 与他的基本比特币 Lisp 语言（bll）和 Simplicity 进行了比较，这两者都将提供替代的脚本语言。Antoine Poinsot 建议，一种易于推理的替代语言可能比对当前系统的小改动风险更小，而当前系统很难推理。开发者 Moonsettler 认为，逐步引入新功能到比特币脚本中使得以后添加更多功能更安全，因为每次增加表达能力都会降低我们遇到意外的可能性。

        Osuntokun 和 James O’Beirne 都批评了 bll 和 Simplicity 与 CTV 和 CSFS 相比的准备程度。

    • ● **CTV+CSFS 的好处： Steven Roose 在 Delving Bitcoin 上发布，建议将 CTV 和 CSFS 添加到比特币作为进一步增加表达能力的其他变更的第一步。大多数讨论集中在限定 CTV、CSFS 或两者一起的可能好处。这包括：

      • ● **DLC： CTV 和 CSFS 单独都可以减少创建 DLC 所需的签名数量，特别是对于签署大量合约变体的 DLC（例如，以一美元为增量的 BTC-USD 价格合约）。Antoine Poinsot 链接到最近一个 DLC 服务提供商宣布关闭的消息，作为比特币用户似乎对 DLC 不太感兴趣的证据，并链接到几个月前 Jonas Nick 的一个帖子，其中说：“DLC 在比特币上没有实现有意义的采用，其有限使用似乎不是源于性能限制”。回复链接到其他仍在运行的 DLC 服务提供商，包括一个声称已经筹集了”3000 万美元融资”的提供商。

      • ● 保管库： CTV 简化了今天在比特币上使用预签名交易和（可选）私钥删除可能实现的保管库的实现。Anthony Towns 认为这种类型的保管库不是很有趣。James O’Beirne 反驳说，CTV 或类似的东西是构建更高级类型保险库的先决条件，例如他的 BIP345 OP_VAULT 保险库。

      • ● 可问责计算合约： CSFS 可以通过替代当前需要执行基于脚本的 lamport 签名的需求，消除 BitVM 等可问责计算合约中的许多步骤。CTV 可能能够减少一些额外的签名操作。Poinsot 再次询问是否对 BitVM 有显著需求。Gregory Sanders 回复说，他会发现它对于代币的双向桥接作为 “暗影客户端验证” 的一部分很有趣（参见周报 #322）。然而，他还指出，CTV 和 CSFS 都不会显著改善 BitVM 的信任模型，而其他变更可能能够以其他方式减少信任或减少昂贵操作的数量。

      • ● **改进 Liquid 时间锁定脚本： James O’Beirne 转述了两位 Blockstream 工程师的评论，用他的话说，CTV 将“极大地改善 [Blockstream] Liquid 时间锁定回退脚本，该脚本要求定期[移动]币”。在要求澄清后，前 Blockstream 工程师 Sanket Kanjalkar 解释说，好处可能是显著节省链上交易费用。O’Beirne 还分享了 Blockstream 研究总监 Andrew Poelstra 的额外细节。

      • ● **LN-Symmetry： CTV 和 CSFS 一起可以用来实现 LN-Symmetry 的一种形式，它消除了 LN 中当前使用的 LN-Penalty 通道的一些缺点，并可能允许创建具有两个以上参与方的通道，这可能改善流动性管理和链上效率。Gregory Sanders，他使用 SIGHASH_ANYPREVOUT（APO）实现了 LN-Symmetry 的实验版本（参见周报 #284），指出CTV+CSFS 版本的 LN-Symmetry 不如 APO 版本功能丰富，并且需要做出权衡。Anthony Towns 补充说，据所知，没有人更新 Sanders 的 APO 实验代码以在现代软件上运行并使用最近引入的中继功能，如 TRUC 和临时锚点，更不用说有人将代码移植到使用 CTV+CSFS，这限制了我们评估该组合用于 LN-Symmetry 的能力。

        Poinsot 询问如果软分叉使其成为可能，实现 LN-Symmetry 是否会成为 LN 开发者的优先事项。来自两位 Core Lightning 开发者（也是引入我们现在称为 LN-Symmetry 的论文的共同作者）的引述表明，这对他们来说是一个优先事项。相比之下，LDK 首席开发者 Matt Corallo 之前表示，“我不认为 [LN-Symmetry] 有趣到 ‘我们得马上行动’”。

      • ● **Ark： Roose 是一家构建 Ark 实现的企业的 CEO。他说，“CTV 对 Ark 来说是如虎添翼 […] CTV 对用户体验的好处是不可否认的，毫无疑问，两种 [Ark] 实现都将在 CTV 可用后立即使用它。”Towns 指出，没有人用 APO 或 CTV 实现 Ark 进行测试；Roose 随后编写了代码，称其“非常直接”，并表示它通过了现有实现的集成测试。他量化了一些改进：“如果我们切换到 CTV，我们可以净减少约 900 行代码 […] 并将我们自己的回合协议减少到[两个]而不是三个，[加上]不必传递签名随机数和部分签名的带宽改进。”

        Roose 后来开始了一个单独的帖子，讨论 CTV 对 Ark 用户的好处（见下面我们的总结）。

    • ● **CTV 对 Ark 用户的好处： Steven Roose 在 Delving Bitcoin 上发布了一个简短描述，介绍了当前部署到 signet 的 Ark 协议，称为 无限制条款的 Ark（clArk），以及 OP_CHECKTEMPLATEVERIFY（CTV）操作码的可用性如何使使用限制条款的协议版本在最终部署到主网时对用户更具吸引力。

      Ark 的一个设计目标是允许异步支付：在接收者离线时进行的支付。在 clArk 中，这是通过支付者加上 Ark 服务器扩展支出者现有的预签名交易链来实现的，允许接收者最终接受对资金的独占控制。该支付被称为 Ark out-of-round 支付（arkoor）。当接收者上线时，他们可以选择他们想要做什么：

      • ● 延迟后退出： 广播整个预签名交易链，退出这个 joinpool（这个 joinpool 就叫 Ark）。这需要等待支付者同意的时间锁到期。当预签名交易被确认到适当深度时，接收者可以确定他们对资金免信任控制。然而，他们失去了作为 joinpool 一部分的好处，如快速结算和源自 UTXO 共享的较低费用。他们可能还需要支付交易费用来确认交易链。

      • ● 什么都不做： 在正常情况下，交易链中的预签名交易最终会到期，允许服务商索取资金。这不是盗窃——这是协议的预期部分——服务商可能选择以某种方式将部分或全部索取的资金返还给用户。在到期临近之前，接收者可以只是等待。

        在病态情况下，服务商和支付者可以（在任何时候）勾结签署另一条交易链以窃取发送给接收者的资金。注意：比特币的隐私属性允许服务商和支付者是同一个人，所以甚至可能不需要勾结。然而，如果接收者保留了服务商共同签署的交易链的副本，他们可以证明服务商窃取了资金，这可能足以阻止其他人使用该服务商。

      • ● 刷新： 在服务器合作的情况下，接收者可以原子地将支出者共同签署的交易中的资金所有权转移到另一个以接收者为共同签署者的预签名交易。这延长了到期日期，并消除了服务商和先前支付者勾结窃取先前发送资金的能力。然而，刷新需要服务商持有刷新的资金直到它们到期，减少了服务商的流动性，所以服务商向接收者收取利率直到到期（由于到期时间是固定的，所以是预先支付）。

      Ark 的另一个设计目标是允许参与者接收 LN 支付。在他的原始帖子和回复中，Roose 描述了现有参与者如果已经在 joinpool 中有资金，如果他们未能执行接收 LN 支付所需的交互，可能会被处罚高达链上交易成本。然而，那些在 joinpool 中还没有资金的人不能被处罚，所以他们可以拒绝执行交互步骤，无成本地为诚实参与者创造问题。这似乎在实质上地阻止了 Ark 用户接收 LN 支付，除非他们已经在他们想要使用的 Ark 服务商处存入了适量的资金。

      Roose 然后描述了 CTV 的可用性如何允许改进协议。主要变化是 Ark 轮次的创建方式。_Ark 轮次_由一个小型链上交易组成，该交易承诺了一棵链下交易树。在 clArk 的情况下，这些是预签名交易，需要该轮次中的所有支付者都可进行签名。如果 CTV 可用，交易树中的每个分支都可以使用 CTV 承诺其后代，无需签名。这允许即使在创建轮次时参与者不可用，也能创建交易，带来以下好处：

      • ● 轮内非交互式支付： 代替 Ark out-of-round（arkoor）支付，愿意等待下一轮的支付者可以在轮内支付给接收者。对于接收者，这有一个主要优势：一旦轮次确认到适当深度，他们就获得对接收资金的免信任控制（直到到期临近，此时他们可以选择退出或低成本刷新）。接收者可以选择立即信任 Ark 协议创建的激励，让服务器诚实运营（参见周报 #253），而不是等待几次确认。在另一点上，Roose 指出，这些非交互式支付也可以批量支付多个接收者。

      • ● **轮内接受 LN 支付： 用户可以请求将 LN 支付（HTLC）发送到 Ark 服务器，服务器随后会持有该支付直到下一轮，并使用 CTV 在该轮中包含一个 HTLC 锁定的支付给用户——之后用户可以披露 HTLC 原象来领取支付。然而，Roose 指出这仍然需要使用“各种反滥用措施”（我们认为这是因为接收者可能不披露原像，导致服务器的资金保持锁定直到 Ark 轮结束，这可能延续两个月或更长时间）。

        David Harding 回复 Roose 请求更多细节，并将这种情况与 LN JIT 通道进行比较，后者也有类似的 HTLC 原象不披露问题，给闪电服务提供商（LSPs）造成麻烦。LSP 目前通过引入基于信任的机制来解决这个问题（见周报 #256）。如果计划在 CTV-Ark 中使用相同的解决方案，这些解决方案似乎也能安全地允许在 clArk 中进行轮内接受 LN 支付。

      • ● 更少的轮次、更少的签名和更少的存储： clArk 使用 MuSig2，每个参与方需要参与多个轮次，生成多个部分签名，并存储完全的签名。使用 CTV，需要生成和存储的数据更少，所需的交互也更少。

  • ● OP_CHECKCONTRACTVERIFY 语义： Salvatore Ingala 在 Delving Bitcoin 上发布了对提议的 OP_CHECKCONTRACTVERIFY（CCV）操作码语义的描述，链接到一个首个 BIP 草案，以及链接到 Bitcoin Core 的实现草案。他的描述从 CCV 行为的概述开始：它允许检查公钥是否承诺了任意数据。它可以检查正在花费的 taproot 输出的公钥或正在创建的 taproot 输出的公钥。这可以用来确保从正在花费的输出中的数据被传递到正在创建的输出。在 taproot 中，输出的调整项可以承诺 tapleave，从而可以携带 tapscripts。如果调整项承诺了一个或多个 tapscripts，它会在输出上放置一个 encumbrance（花费条件），（然后 CCV 就）允许放置在正在花费的输出上的条件被转移到正在创建的输出上——在比特币术语中通常（但有争议地）称为限制条款。这种限制条款可能允许满足或修改 encumbrance，这将（分别）终止限制条款或修改其未来迭代的条款。Ingala 描述了这种方法的一些优点和缺点：

    • ● 优点： taproot 原生，不增加 UTXO 集里 taproot 条目的大小，不需要额外数据的花费路径不需要在其见证栈中包含它（所以在这种情况下没有额外成本）。

    • ● 缺点： 只适用于 taproot，检查调整需要椭圆曲线操作，这比（例如）SHA256 操作更昂贵。

    仅将花费条件从正在花费的输出转移到正在创建的输出可能是有用的，但许多限制条款会希望确保正在花费的输出中的部分或全部比特币被传递到正在创建的输出。Ingala 描述了 CCV 处理值的三个选项。

    • ● 忽略： 不检查金额。

    • ● 扣除： 在特定索引（例如，第三个输出）创建的输出的金额从同一索引处花费的输出的金额中扣除，并跟踪剩余值。例如，如果索引三处花费的输出价值 100 BTC，而索引三处创建的输出价值 70 BTC，则代码会跟踪剩余的 30 BTC。如果创建的输出大于花费的输出，则交易被标记为无效（因为这会减少剩余值，可能低于零）。

    • ● 默认： 除非在特定索引创建的输出的金额大于花费的输出的金额加上尚未使用 default 检查的任何先前剩余值的总和，否则将交易标记为无效。

    如果任何输出被 deduct 检查多次，或者如果 deduct 和 default 都用于同一输出，则交易有效。

    Ingala 提供了上述操作组合的几个可视化示例。以下是我们对他的“发送部分金额”示例的文字描述，这可能对保管库有用：一个交易有一个输入（花费一个输出）价值 100 BTC 和两个输出，一个 70 BTC，另一个 30 BTC。CCV 在交易验证期间运行两次：

    1. CCV 使用 deduct 操作索引 0，从 100 BTC 花费到 70 BTC 创建，得到 30 的剩余值。在 BIP345 风格的保管库中，CCV 将把那 70 BTC 返回到之前保护它的相同脚本。

    2. 第二次，它在索引 1 上使用 default。虽然在这个交易中索引 1 处有一个正在创建的输出，但索引 1 处没有相应的正在花费的输出，所以使用隐式金额 0。将索引 0 上 deduct 调用的剩余 30 BTC 添加到该零值，要求创建的这个输出等于或大于 30 BTC。在 BIP345 风格的保管库中，CCV 会调整输出脚本，允许在时间锁到期后将此值花费到任意地址，或随时将其返回到用户的主保管库地址。

    Ingala 考虑并放弃的几种替代方法在他的帖子和回复中都有讨论。他写道，“我认为这两种金额行为（default 和 deduct）非常符合人体工程学，并且涵盖了实践中绝大多数理想的金额检查。”

    他还指出，他“使用 OP_CCV 加上 OP_CTV 实现了功能齐全的保管库，大致相当于 […BIP345…]。此外，仅使用 OP_CCV 的减少功能版本在 OP_CCV 的 Bitcoin Core 实现中作为功能测试实现。”

  • ● 共识清理的 BIP 草案发布： Antoine Poinsot 在 Bitcoin-Dev 邮件列表上发布了他为共识清理软分叉提案编写的BIP 草案链接。它包括几个修复：

    • 修复两种不同的时间扭曲攻击，这些攻击可能被大多数算力用来加快速率产生区块。

    • 对传统交易的签名操作（sigops）执行限制，以防止创建验证过慢的区块。

    • 修复 BIP34 coinbase 交易唯一性，应该完全防止重复交易。

    • 使未来的 64 字节交易（使用剥离大小计算）无效，以防止一种默克尔树漏洞。

    技术回复对提案的所有部分都表示赞同，除了两个部分。第一个反对意见，在几个回复中提出，是关于使 64 字节交易无效。这些回复重申了先前的批评（见周报 #319）。存在一种解决默克尔树漏洞的替代方法。该方法对轻量级（SPV）钱包使用相对容易，但可能对智能合约中的 SPV 验证带来挑战，例如比特币和其他系统之间的 桥。Sjors Provoost 建议实现链上可执行桥的人提供代码，说明能够假设 64 字节交易不存在与必须使用替代方法防止默克尔树漏洞之间的区别。

    第二个反对意见是关于 BIP 中包含的想法的后期变更，这在 Poinsot 在 Delving Bitcoin 上的帖子中有描述。该变更要求共识清理激活后生产的区块设置使其 coinbase 交易时间锁可执行的标志。按照先前的提议，激活后区块中的 coinbase 交易将把它们的时间锁设置为它们的区块高度（减 1）。这一变更意味着没有矿工可以产生一个早期比特币区块的替代，同时使用激活后的时间锁并设置执行标志（因为如果他们这样做，由于使用了远期时间锁，他们的 coinbase 交易在包含它的区块中将无效）。无法在过去的 coinbase 交易中使用与未来coinbase 交易中将使用的完全相同的值，防止了重复交易漏洞。对这一提议的反对意见是，尚不清楚所有矿工是否能够设置时间锁执行标志。

版本和候选版本

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

  • ● BDK wallet 1.2.0 增加了向自定义脚本发送支付的灵活性，修复了与 coinbase 交易相关的边缘情况，并包括其他几个功能和错误修复。

  • ● LDK v0.1.2 是这个用于构建支持 LN 的应用程序的库的发布版本。它包含几个性能改进和错误修复。

  • ● Bitcoin Core 29.0rc3 是网络中占主导地位的全节点的下一个主要版本的候选版本。请参阅版本 29 测试指南。

  • ● LND 0.19.0-beta.rc1 是这个热门的 LN 节点的候选版本。可能需要测试的主要改进之一是基于 RBF 的合作关闭手续费提升。

重要的代码和文档变更

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

  • ● Bitcoin Core #31363 引入了 TxGraph 类（见周报 #341），这是一个轻量级的内存中交易池交易模型，只跟踪手续费率和交易之间的依赖关系。它包括诸如 AddTransaction、RemoveTransaction 和 AddDependency 等变异函数，以及诸如 GetAncestors、GetCluster 和 CountDistinctClusters 等检查函数。TxGraph 还支持带有提交和中止功能的变更暂存。这是族群交易池项目的一部分，为未来的交易池驱逐、重组处理和族群感知挖矿逻辑的改进做准备。

  • ● Bitcoin Core #31278 弃用了 settxfee RPC 命令和 -paytxfee 启动选项，这些允许用户为所有交易设置静态手续费率。用户应该改为依赖手续费估算或设置每笔交易的手续费率。它们被标记为在 Bitcoin Core 31.0 中移除。

  • ● Eclair #3050 更新了当接收者是直接连接的节点时 BOLT12 支付失败的中继方式，始终转发失败消息而不是用不可读的 invalidOnionBlinding 失败覆盖它。如果失败包括 channel_update，Eclair 用 TemporaryNodeFailure 覆盖它以避免揭示关于未公告通道的详细信息。对于涉及其他节点的盲路由，Eclair 继续用 invalidOnionBlinding 覆盖失败。所有失败消息都使用钱包的 blinded_node_id 加密。

  • ● Eclair #2963 通过在通道强制关闭期间调用 Bitcoin Core 的 submitpackage RPC 命令来实现一父一子（1p1c）包中继，同时广播承诺交易及其锚点。这允许承诺交易传播，即使它们的手续费率低于交易池最低要求，但需要连接到运行 Bitcoin Core 28.0 或更高版本的对等节点。这一变更消除了动态设置承诺交易手续费率的需要，并确保当节点对当前手续费率有分歧时，强制关闭不会被卡住。

  • ● Eclair #3045 使外部洋葱载荷中的 payment_secret 字段对单部分蹦床支付是可选的。以前，每个蹦床支付都包括一个 payment_secret，即使没有使用多路径支付（MPP）。由于在处理现代 BOLT11 发票时可能需要支付密钥，如果没有提供，Eclair 在解密时插入一个虚拟密钥。

  • ● LDK #3670 添加了处理和接收蹦床支付的支持，但尚未实现提供蹦床路由服务。这是 LDK 计划部署的一种异步支付类型的先决条件。

  • ● LND #9620 通过添加必要的参数和区块链常量（如其创世哈希）来添加 testnet4 支持。