本周的周报宣布了支持 utreexo 的全节点的测试版，并总结了 BIP119 OP_CHECKTEMPLATEVERIFY 的两个扩展提议。此外，还包括我们的常规部分：其中包括新版本和候选版本的公告，以及对热门比特币基础设施项目的重大变更介绍。

新闻

  • ● utreexod 测试版发布： Calvin Kim 在 Bitcoin-Dev 邮件列表中宣布了支持 utreexo 的全节点 utreexod 的测试版发布。utreexo 允许节点存储 UTXO 集状态的小型承诺，而不是整个集合本身；例如，最小承诺可以为 32 字节，而当前完整集合约为 12 GB，这使得承诺大约小了 10 亿倍。为了减少带宽，utreexo 可能会存储额外的承诺，增加磁盘使用空间，但仍将其链状态保持在比传统全节点小一百万倍左右的数量级。同时剪枝旧区块的 utreexo 节点可以在少量恒定的磁盘空间中运行，而即使是剪枝的常规完整节点，其链状态也可能超出设备存储容量的范围。

    Kim 发布的版本注释显示，该节点与基于 BDK 的钱包兼容，此外通过对 Electrum 个人服务器的支持，也可以支持许多其他钱包。该节点支持通过扩展 P2P 网络协议来中继 utreexo 证明的交易中继。支持_常规_和 _桥_两种 utreexo 节点；常规 utreexo 节点使用 utreexo 承诺来节省磁盘空间；而桥节点则存储完整的 UTXO 状态以及一些额外数据，并可以为尚不支持 utreexo 的节点和钱包创建的区块和交易附加 utreexo 证明。

    Utreexo 不需要共识更改，utreexo 节点也不会干扰非 utreexo 节点，尽管常规 utreexo 节点只能与其他常规 utreexo 节点和桥节点成为对等节点。

    Kim 在公告中包含了几个警告：“代码和协议尚未经过同行评审[…]将会有重大更改[…] utreexod 是基于 btcd [可能存在]的共识不兼容性”。

  • ● BIP119 扩展支持更小的哈希和任意数据承诺： Jeremy Rubin 在 Bitcoin-Dev 邮件列表中 发布了一个拟议的 BIP，以扩展提案 OP_CHECKTEMPLATEVERIFY (OP_CTV) 并附加两个功能：

    • ● 支持 HASH160 哈希： 这些是用于 P2PKH、P2SH 和 P2WPKH 地址的哈希摘要。它们为 20 字节，而基础 BIP119 提案中使用的哈希摘要为 32 字节。在朴素的多方协议中，针对 20 字节哈希的碰撞攻击可以在大约 280 次暴力操作中执行，这对积极性高的攻击者并非难事。因此，现代比特币操作码通常使用 32 字节哈希摘要。然而，在单方协议或使用 20 字节哈希的精良设计多方协议中，安全性可以提高到不太可能在少于约 2160 次暴力操作中被破坏，从而允许这些协议在每个摘要节省约 12 字节。一个可能有用的案例是在 eltoo 协议(见周报 #284)中实现。

    • ● 支持其他承诺： 仅当在包含输入和输出的交易中执行 OP_CTV 且这些输入和输出的哈希值与提供的哈希摘要相同，它才会被执行成功。其中一个输出可以是 OP_RETURN 输出，该输出提交脚本创建者希望发布到区块链的某些数据，例如从备份中恢复 LN 通道状态所需的数据。然而，将数据放在见证字段中的成本会大大降低。更新后的 OP_CTV 形式允许脚本创建者要求在对输入和输出进行哈希处理时包含来自见证堆栈的额外数据。该数据将与脚本创建者提供的哈希摘要进行对比检查。这可确保以最小的区块重量将数据发布到区块链。

    截至撰写本文时，该提议尚未在邮件列表中收到任何讨论。

版本和候选版本

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

重大的代码和文档变更

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

  • ● Bitcoin Core #29845 更新了多个 get*info RPC，以将 warnings 字段从字符串更改为字符串数组，以便可以返回多个警告，而不仅仅是一个。

  • ● Core Lightning #7111 通过 libplugin 实用程序将 check RPC 命令提供给插件。通过启用使得配置选择生效的 check setconfig 来扩展使用范围，并且现存的 check keysend 现在验证 hsmd 是否会批准交易。预初始化消息已经被添加了带有预设 HSM 开发标志。有关 check 命令的更多参考，见周报#25和#47。

  • ● Libsecp256k1 #1518 添加了一个 secp256k1_pubkey_sort 函数，该函数将一组公钥按规范顺序排序。这对于 MuSig2 和静默支付都很有用，可能还包括许多其他涉及多个密钥的协议。

  • ● Rust Bitcoin #2707 更新了作为 taproot 的一部分引入的标记哈希的 API，以期在默认情况下，摘要为_内部字节顺序_。之前，API 期望哈希值为_显示字节顺序_，这种顺序现在可以使用诸如 #[hash_newtype(backward)] 的代码获得。由于历史原因，txid 和 区块标识符哈希摘要在交易和区块内以一种字节顺序（内部字节顺序）出现，但在用户界面中以相反的顺序（显示字节顺序）显示和调用。该 PR 试图防止更多哈希在不同情况下使用不同的字节顺序。

  • ● BIPs #1389 添加了 BIP388，其中描述了“描述符钱包的钱包策略”，这是一组经过模板化的输出脚本描述符，可能更容易被广泛的钱包在代码和用户界面中支持。特别是，在资源和屏幕空间有限的硬件钱包上实现描述符可能具有挑战性。BIP388 钱包策略允许选择加入的软件和硬件对如何使用描述符做出假设简化；这将描述符的范围降到最小，减少了所需的代码量和需要用户验证的细节数量。任何需要描述符全部功能的软件仍然可以独立于 BIP388 使用它们。有关更多信息，见周报 #200。

  • ● BIPs #1567 添加了 BIP387，其中包括 multi_a() 和 sortedmulti_a() 描述符，它们在 tapscript 中提供脚本化的多签名功能。以 BIP 中的一个示例，描述符片段 multi_a(k,KEY_1,KEY_2,...,KEY_n) 将生成类似 KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUAL 的脚本。见周报#191、#227 和 #273。

  • ● BIPs #1525 添加了 BIP347，其中提出了 OP_CAT 操作码，如果在软分叉中激活，可以在 tapscript 中使用。另请见周报 #274、#275 和 #293。

周报发布日期变更

在接下来的几周内，Optech 将尝试其他发布日期。如果您提前或延迟几天收到周报，请不要感到惊讶。在短暂的实验期间，我们通过电子邮件发送的周报将包括一个跟踪器，以帮助我们确定有多少人阅读了周报。您可以通过在阅读周报之前禁用外部资源的加载来防止跟踪。如果您想要更多的隐私，我们建议您通过临时的 Tor 连接订阅我们的RSS feed。对于给您带来的不便，我们深表歉意。