本周的通讯介绍了对短暂锚点（ephemeral anchor）提案的更新，并提供了来自 Wizardsardine 的开发人员的有关 Miniscript 的贡献领域报告。还包括每期固定内容，宣布新的软件发布和发布候选版本，并总结了一些流行的比特币基础设施项目的重大变化。

News

消除短暂锚点 spend 中的可篡改性：Gregory Sanders 在 Delving Bitcoin 论坛上发布了一项对短暂锚点提案的微调。该提案允许交易包含一个零价值输出和一个任何人都能 spend 的输出脚本。由于任何人都可以 spend 输出，因此任何人都可以使用 CPFP 费用提升创建输出的交易。这对于多方合同协议（如 LN）非常方便，因为交易经常在准确预测应支付的费率之前签名。短暂锚点允许合同的任何一方添加他们认为必要的费用。如果任何其他方或任何其他用户出于任何原因想要添加更高的费用，他们可以用自己的更高费率的 CPFP 费用提升替换原始的 CPFP 费用提升。

建议使用由等效于 OP_TRUE 的输出脚本组成的任何人都能 spend 脚本的类型，它可以由具有空输入脚本的输入 spend。正如 Sanders 本周发布的那样，使用传统的输出脚本意味着 spend 它的子交易具有可篡改的 txid，例如，任何矿工都可以向输入脚本添加数据以更改子交易的 txid。这可能使得除了费用提升之外，不明智地使用子交易，因为即使能够确认，也可能会是以使任何孙交易（grandchild transactions）无效的不同 txid 得到确认。

Sanders 建议改用为未来 segwit 升级保留的输出脚本之一。虽然这会略微增加块空间，对于 segwit 来说是四个字节，而对于 OP_TRUE 来说是一个字节，但它消除了对交易可篡改性的所有担忧。在该主题基础上进行了一些讨论后，Sanders 随后提议提出两点：一个适用于不关心可篡改性且希望最小化交易大小的 OP_TRUE 版本，以及一个略大但不允许子交易发生变化的 segwit 版本。主题中的其他讨论集中在选择用于 segwit 方法的额外字节，以创建一个值得记住的 bech32m 地址。

领域报告：Miniscript 之旅

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

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

实际上，我们怀疑我们在演示中使用的脚本是安全的吗？它是否可以以它宣传的所有方式 spend？除了这些宣传方式外，是否有其他方式 spend？

即使是这样，我们如何将其推广到不同的参与者并保持安全？如何做出一些优化，并确保生成的脚本具有相同的语义？

此外，Revault 正在使用预签名的交易（以强制执行 spend 政策）。如何事先知道根据脚本的配置为费用提升分配的预算？如何确保 spend 这些脚本的任何交易都通过最常见的标准性检查？

最后，即使假设我们的脚本符合预期的语义并且始终可 spend，我们如何具体 spend 它们？也就是说，我们如何为每种可能的配置生成令人满意的见证（「签名」）？如何使硬件签名设备与我们的脚本兼容？

如果没有 Miniscript，这些问题本应是一个阻碍因素。车库的两个人不会编写一个可以临时创建脚本的软件，最重要的是，称其为增强安全性的比特币钱包。我们想要围绕 Revault 的开发创建一家公司，但如果不能向投资者提供我们能够推出安全产品的有效保证，我们将无法获得资金。而没有资金，我们将无法解决所有这些工程问题。

Miniscript 应运而生，「一种以结构化方式编写（Bitcoin 脚本子集的）语言，支持分析、组合、通用签名等。它具有一种允许组合的结构。对于各种属性（spend 条件、正确性、安全性质、可篡改性等）进行静态分析非常容易。」这正是我们需要的。凭借这个强大的工具，我们可以向我们的投资者提供更好的保证，从而筹集资金，并开始开发 Revault。

当时，Miniscript 距离成为任何比特币应用程序开发人员可用的即插即用解决方案还有很长的路要走。（如果您是在 2023 年之后阅读此文的新比特币开发人员，要知道我们曾经需要用手写比特币脚本。）我们不得不将 Miniscript 集成到 Bitcoin Core 中（参见 PRs＃24147、＃24148 和＃24149），我们将其用作 Revault 钱包的后端，并说服签名设备制造商在其固件中实现它。事实证明后者是最困难的部分。

这是一个先有鸡还是先有蛋的问题：制造商在没有用户需求的情况下实施 Miniscript 的动力较低，而且没有签名设备的支持，我们无法发布 Revault。幸运的是，这个循环最终在 2021 年 3 月由 Stepan Snigirev 打破，他为 Specter DIY 引入了对 Miniscript 描述符的支持。然而，Specter DIY 很长一段时间被称为仅仅是一个「功能原型」，Salvatore Ingala 在 2022 年首次将 Miniscript 引入到 Ledger Nano S(+) 的新比特币应用中，这一应用于 2023 年 1 月发布，使我们能够推出支持最受欢迎签名设备的 Liana 钱包。

我们的 Miniscript 之旅还剩下一个发展。Liana 是一个专注于恢复选项的比特币钱包。它允许用户指定一些有时间锁定的恢复条件（例如，第三方恢复密钥通常无法 spend 资金，或者是一个逐渐扩展的多签）。最初 Miniscript 仅适用于 P2WSH 脚本。不幸的是，在 Taproot 激活近 2 年后，每次 spend 时都必须在链上发布恢复路径。为此，我们一直在努力将 Miniscript 移植到 Tapscript。

随着大多数签名设备已经实施或正在实施 Miniscript 支持（例如最近的 Bitbox 和 Coldcard），以及 Taproot 和 Miniscript 本地框架的不断完善，使用安全基元在比特币上进行合约更加容易。

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

当然还存在风险，但至少我们有信心能够解决链上的部分。预料之外的是，链下部分证明更具挑战性。

版本发布和候选版本

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

LND 0.17.1-beta 是这个闪电网络节点实现的维护版本，包括一些错误修复和小的改进。

Bitcoin Core 26.0rc2 是这个主要全节点实现的下一个主要版本的候选版本。有一个测试指南，以及定于 2023 年 11 月 15 日的比特币核心 PR 审查俱乐部专注于测试的预定会议。

Core Lightning 23.11rc1 是这个闪电网络节点实现的下一个主要版本的候选版本。

代码和文档变更

Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、硬件钱包接口（HWI）、Rust Bitcoin、BTCPay Server、BDK、比特币改进提案（BIPs）、闪电 BOLTs 以及比特币审讯中的一些显著变更。

Bitcoin Core #28207 更新了磁盘上存储内存池的方式（通常发生在节点关闭期间，但也可以通过 savemempool RPC 触发）。先前，它是以基础数据的简单序列化形式存储的。现在，该序列化结构会被每个节点独立生成的随机值进行异或运算，以混淆数据。在加载期间，使用相同的值进行异或运算以消除混淆。混淆防止有人能够在交易中放入某些数据，以使特定的字节序列出现在保存的内存池数据中，这可能导致病毒扫描程序等程序将保存的内存池数据标记为危险。相同的方法之前已应用于在 PR #6650 中存储 UTXO 集。任何需要从磁盘读取内存池数据的软件都应该可以轻松地应用 XOR 操作本身，或使用配置设置 -persistmempoolv1 以请求以未混淆的格式保存。请注意，向后兼容的配置设置计划在将来的版本中删除。

LDK #2715 允许节点选择性地接受比应该交付的较小值的 HTLC。当上游对等方通过新的 JIT 通道支付节点时，这是有用的，该通道会对上游对等方产生一笔在链上的交易费用，他们希望从支付给节点的 HTLC 金额中扣除。