本周的周报介绍了对临时锚点提案的更新，并附上了来自 Wizardsardine 开发人员关于 miniScript 的贡献性工作报告。还包括我们的常规部分：新软件版本和候选版本的公告，以及对热门比特币基础设施项目的重大变更介绍。

新闻

  • ● 从临时锚点花费中消除熔融性： Gregory Sanders 在 Delving Bitcoin 论坛上发表了一个对临时锚点提案的微调。该提案将允许交易包括一个零价值输出，其输出脚本为任何人都可以花费。由于任何人都可以花费输出，因此任何人都可以使用 CPFP 来对创建这个输出的交易进行费用提升。这对于诸如 LN 等多方合同协议非常方便，因为交易通常会在能够准确预测应支付的费率之前签署。临时锚定点允许合约任何一方添加他们认为必要的费用。如果任何其他一方，或者任何其他用户出于任何原因，想要添加更高费用，则他们可以用自己更高费率的 CPFP 费用提升来替代之前的 CPFP 费用提升。

    提议使用的任何人都可以花费的脚本类型是一个输出脚本，它由等效的 OP_TRUE 组成，可以通过具有空输入脚本的输入进行花费。正如Sanders 本周发布的那样，使用传统输出脚本意味着花费它的子交易具有可熔铸变型的交易索引号（txid），例如，任何矿工都可以向输入脚本添加数据以更改子交易的 txid。这可以使得除了用于费用增加之外，将该子交易用于任何其他用途都是不明智的，因为即使子交易得到确认，也可能以不同的 txid 确认，从而使任何孙交易无效。

    Sanders 建议改用原先为后来隔离见证（Segwit）升级所保留的输出脚本之一。这会使用略多的区块空间————SegWit 使用四个字节，而裸的 OP_TRUE 仅使用一个字节，但可以消除关于交易熔融性的任何顾虑。在该主题上进行了一些讨论后，Sanders 随后提出同时提供两种版本：一个 OP_TRUE 版本，适用于不关心熔融性且希望尽量减小交易大小的人，以及一个 SegWit 版本，略大但不允许子交易被变异。此讨论主题的进一步探讨侧重于为 SegWit 版本选择额外字节以创建一个易于记忆的 bech32m 地址。

田野调查：一段 Miniscript 旅程

by Antoine Poinsot from Wizardsardine

我们对 Miniscript 的（实际）兴趣始于2020年初，当时我们正在设计 Revault，这是一种仅使用当时可用的脚本原语的多方（保险柜）vault 架构。

在最初的演示用途中，Revault 总是使用一组固定的参与者。当我们试图将其推广到生产环境中的更多参与者时，我们很快遇到了问题。

  • 实际上，我们 确定 演示中使用的脚本是安全的吗？我们广告上的所有花费办法都一定能成功吗？除了广告上的办法，还有没有其他花费它的方法？
  • 即使是这样，我们如何将其推广到允许数量不等的参与者，并保持安全性？我们如何应用一些优化措施，并确保生成的脚本具有相同的语义？
  • 此外，Revault 使用预签名交易（以强制执行花费规则）。给定脚本的配置，我们如何提前知道为费用提升分配多少预算？我们如何确保使用这些脚本进行的 任何 交易都能通过最常见的标准性检查？
  • 最后，即使我们假设我们的脚本与预期的语义相对应，并且始终可以花费，我们如何 具体地 花费它们呢？就是说，我们如何为每一种可能的配置生成令人满意的见证（“签名”）？我们如何使硬件签名设备与我们的脚本兼容呢？

如果没有 Miniscript，这些问题本来可能成为绊脚石。两个在车库里的人不太可能编写出一款能够即时创建某些脚本的软件、指望它可以取得最好的结果并基于此称之为增强安全性的比特币钱包。我们想要围绕 Revault 的开发启动一家公司，但如果不能向投资者提供合理的保证，证明我们能够将安全的产品带到市场上，我们就无法获得资金支持。如果没有资金，我们也无法解决所有这些工程问题。

进入 miniscript，“这是一种用结构化方式编写比特币脚本（子集）的语言，使分析、组合、通用签名等功能成为可能[…]它具有允许组合的结构，非常容易静态分析，以验证各种属性(花费条件、正确性、安全属性、熔融性等)”。这正是我们所需要的。凭借这个强大的工具，我们可以为我们的投资者提供更好的保证[0]，筹集资金，并开始 Revault 的开发。

当时，miniscript 距离成为任何比特币应用程序开发人员可以使用的成套解决方案还很遥远。(如果你是 2023 年之后阅读这篇文章的新比特币开发人员，是的，曾经我们手动编写比特币脚本)。我们不得不将 miniscript 集成到 Bitcoin Core 中(见 PRs #24147、#24148和#24149)，并将其用作 Revault 钱包的后端，且说服签名设备制造商在他们的固件中实现它。后半部分将是最困难的。

这是一个先有鸡还是先有蛋的问题：在没有用户需求的情况下，制造商实现 miniscript 的动机很低，并且我们无法在没有签名设备支持的情况下发布 Revault。幸运的是，这一循环最终在 2021 年 3 月被 Stepan Snigirev 打破，他为 Specter DIY带来github embit descriptors对 miniscript 描述符的支持。然而，Specter DIY 长时间被声明为仅仅是一个“功能原型”，是 Salvatore Ingala 在 2022 年首次将 miniscript 带到了生产就绪的签名设备上，推出了适用于 Ledger Nano S（+）的新比特币应用程序。该应用程序于 2023 年 1 月发布，才使我们能够发布支持最流行签名设备的Liana 钱包。

还剩下最后一个开发工作来结束我们的 Miniscript 旅程。Liana 是一个专注于钱包恢复选项的比特币钱包。它允许指定一些带时间锁的恢复条件 (例如第三方恢复密钥，它们通常不能花费资金，或衰减/扩张的多重签名)。最初，Miniscript 仅适用于 P2WSH 脚本。但在 taproot激活两年后，每次花钱都必须在链上发布你的恢复花费路径是令人遗憾的。为此，我们一直在努力将 miniscript 移植到 tapscript 中(见此处和此处)。

未来是光明的。大多数签名设备已经实施或正在实施 miniscript 支持(例如最近的 Bitbox 和 Coldcard)，加上 taproot 和 miniscript 原生框架的完善，使用安全原语在比特币上签约比以往任何时候都更容易。

有趣的是，开源工具和框架的资金支持降低了创新公司竞争的门槛，更广泛地说，降低了要实施的项目的门槛。这种趋势在过去几年中加速发展，让我们对这个领域的未来充满希望。

[0] 当然，仍然存在风险。但至少我们有信心能够克服链上的部分。链下部分（正如预期的那样）将证明更具挑战性。

版本和候选版本

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

重大的代码和文档变更

本周的重大变更有：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 #28207 更新了交易池在磁盘上存储的方式(通常在节点关闭时发生，但也可以通过 savemempool RPC 触发)。之前，它是以底层数据的简单序列化形式存储的。现在，该序列化结构被每个节点独立生成的随机值进行异或（XOR）操作，从而模糊化数据。在加载时，使用相同的值进行异或操作以消除模糊化。模糊处理可防止某人能够在交易中放置某些数据以使特定字节序列出现在保存的交易池数据中，这可能导致病毒扫描程序将保存的交易池数据标记为危险。之前已经应用了相同的方法来存储 UTXO 集在PR #6650。任何需要从磁盘读取交易池数据的软件都应该能够轻松地应用异或操作，或者使用配置设置 -persistmempoolv1 来请求以未模糊的格式来保存。需要注意的是，向后兼容的配置设置计划在未来的版本中被移除。

  • ● LDK #2715 允许节点选择性地接受一个小于应交付的 HTLC值的支付。当上游节点通过新的JIT 通道向节点支付费用时，这非常有用，因为这样上游节点将从要支付给节点的 HTLC 金额中减去链上交易费用。有关 LDK 对该功能上游部分的先前实现，见周报 #257。