本周的周报总结了一种防止 coinjoin 交易钉死攻击的方法，并描述了一种吸引人们为被期待的共识变更投机的提议。此外，还有我们关于交易池规则的限定系列，以及我们的常规部分：其中包括来自 Bitcoin Stack Exchange 的热门问题和答案、新版本和发布候选版本的公告以及流行的比特币基础设施软件的变更。

新闻

• ● 使用 v3 交易中继防止 coinjoin 交易钉死攻击： Greg Sanders 在 Bitcoin-Dev 邮件列表中为提议的 v3 交易中继规则 发帖，描述了如何创建一个不容易受到交易钉死攻击的 coinjoin 风格的多方交易。交易钉死的具体问题是，coinjoin 中的一个参与者可以用他们在交易中的输入创建一个冲突的交易，从而阻止 coinjoin 交易得到确认。

  Sanders 提出 coinjoin 风格的交易可以避免这个问题。这是通过让每个参与者最初将比特币花费到一个只能由所有参与者的签名或者在时间锁过期后只能由参与者自己花费的脚本来实现。另一种办法是，对于一个协调好的 coinjoin 交易，协调者和参与者必须一起签名（或者在时间锁过期后，参与者单独签名）。

  在时间锁过期之前，参与者必须让其他方或协调者共同签名所有冲突的交易。而这是不太可能的，除非该签名对所有参与者都有利（例如手续费替换）。

• ● 投机性地使用期望的共识变化： Robin Linus 在 Bitcoin-Dev 邮件列表上发布了一个关于将资金花费到一个在很长一段时间内（例如 20 年）无法执行的脚本片段的想法。如果根据当前共识规则解释该脚本片段，它将允许矿工在 20 年后取回支付给它的所有资金。然而，该片段中的一些设计使得共识规则的升级将会赋予该片段不同的含义。Linus 举了一个例子，如果在比特币中添加了 OP_ZKP_VERIFY 操作码，将允许任何提供具有特定哈希的程序的零知识证明（ZKP）的人取回资金。

  这将允许人们今天支付 BTC 到其中一个脚本，并使用该花费的证明来在侧链或另一条链上获得等值的 BTC，称为 单向锚定。另一条链上的 BTC 在脚本时间锁过期前的 20 年里可被反复花费。然后，这条链上的 BTC 的当前所有者可以生成一个零知识证明来证明他们拥有它，并使用该证明在比特币主网上提取锁定的存款，从而实现 双向锚定。通过精心设计的验证程序，取款将变得简单和灵活，从而允许同质化的取款。

  作者指出，任何从这种构造中受益的人（例如，在另一条链上接收 BTC 的人）基本上是在赌比特币的共识规则将会改变（例如，添加OP_ZKP_VERIFY）。这会激励他们来拥护这种改变，但过渡激励一些用户来改变系统可能会使另一些用户感到强迫。截止编写本文时，该想法在邮件列表里还没有收到任何讨论。

等待确认 #7：网络资源

这是一个关于交易转发、交易池纳入以及挖矿选择的限定周刊系列 —— 解释了为什么 Bitcoin Core 设置了比共识规则更严格的交易池规则，以及钱包可以如何更高效地使用这些交易池规则。

前一篇文章讨论了保护节点资源的问题。由于各个节点的资源不同，因此有些规则是可配置的。我们还提出了为什么最好统一规则的理由，但是哪些内容应该包含在这个规则里呢？本文将讨论网络范围的资源概念，这对于可扩展性、可升级性、启动和维护全节点的可访问性等方面至关重要。

正如在之前的文章中讨论的那样，比特币网络的许多意识形态目标体现在其分布式结构中。比特币的点对点性质允许网络规则从各个节点运营者所选择的粗略共识中产生，同时抑制在网络中获取不当影响力的企图。然后这些规则由每个节点通过对每个交易进行独立验证来强制执行。一个多样化和健康的节点群体需要保持节点运营成本低廉。不论什么项目，扩展到全球规模都很困难；如果还不想牺牲去中心化，就如同反绑一只手跟人打架。比特币项目通过严格保护其共享的网络资源（UTXO 集、区块链的数据足迹、处理数据所需的计算工作量，以及演化比特币协议的升级钩子）来尝试实现这种平衡。

我们无需重述整个区块体积战争来认识到限制区块链增长是必要的、我们以此来保证个人运行得起自己的节点。但是，区块链的增长在交易池规则层面上也会得到抑制：minRelayTxFee 的值为 1 sat/vbyte，表示了“对超多副本的永久存储的无限需求”的最低成本。

最初，网络状态是通过保留所有仍有未花费输出的交易来跟踪的。随着 UTXO 集作为跟踪资金的手段引入，区块链的这一部分大大减少了。自那时以来，UTXO 集一直是一个核心数据结构。普遍情况下，UTXO 查找占据了节点所有内存访问的主要部分（在初始化区块下载（IBD）期间尤其如此）。Bitcoin Core 已经使用了一个手动优化的 UTXO 缓存的数据结构，但 UTXO 集的大小也决定了集合中有多少交易无法进入节点的缓存。较大的 UTXO 集意味着更多的缓存未命中，这会降低区块验证、IBD 和交易验证的速度。粉尘限制是一种限制 UTXO 创建的策略，特别是限制那些可能永远不会被花费的 UTXO，因为它们的金额不足以支付它们的成本。即便如此，规模达数千笔交易的“粉尘风暴”近在 2020 年仍发生过。

当使用裸多签输出将数据发布到区块链上变得流行起来时，标准交易的定义被修改，允许使用单个 OP_RETURN 输出作为替代方案。人们意识到，无法阻止用户在区块链上发布数据，但至少这些数据不需要永远存在于 UTXO 集中。Bitcoin Core 0.13.0 引入了一个启动选项 -permitbaremultisig，用户可以切换以拒绝带有裸多签输出的未确认交易。

尽管共识规则允许自由格式的输出脚本，但 Bitcoin Core 节点只会中继少数一些被较好理解了的模式。这样更容易推理网络中的许多问题，包括验证成本和协议升级机制等。例如，输入脚本中包含了操作码、P2SH输入中的签名超过 15 个、P2WSH 输入的见证堆栈超过 100 个项，任何一个都将使该交易成为非标准交易（请查看此交易池规则概述以获取更多规则示例及其动机）。

最后，比特币协议是一个不断发展的软件项目，需要不断演进以应对未来的挑战和用户需求。为此，有一些升级钩子被故意保留为共识有效但未使用，例如附录、taproot 叶子版本、见证版本、OP_SUCCESS 以及一些 no-op 操作码。然而，就像因为没有单点故障而阻碍了攻击一样，网络范围下的软件升级要涉及到协调数以万计的独立节点运营者。在其含义被明确定义前，节点不会转发使用了保留的升级钩子的交易。这种阻碍旨在防止应用程序各自独立地创建相互冲突的标准。这种冲突使得共识无法在采用一个应用程序的标准的同时避免另一个标准无效。 此外，当共识真的发生变更时，没有立即升级的节点（因此不了解新的共识规则）无法“被骗”去接受一个现在无效的交易进入他们的交易池中。这种主动阻碍方式可以帮助节点具备向前兼容性，并使网络能够安全升级共识规则而不需要完全同步地进行软件升级。

我们可以看到，使用交易池规则来保护共享网络资源有助于保护网络的特性，并使未来协议的开发路径保持开放。与此同时，我们正在看到，如何在严格限制区块重量的情况下来扩展网络的矛盾正在推动着最佳实践、良好的技术设计和创新的采用：下周的文章将探讨交易池规则作为二层协议和智能合约系统的接口。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange是 Optech 贡献者寻找问题答案或者是我们在空闲时间来帮助好奇或困惑用户的首要场所之一。在这个月度专题中，我们重点介绍了自上次更新以来发布的一些投票最高的问题和答案。

• ● 为什么比特币节点会接受有很多被排除交易的区块？ 用户 commstark 想知道，为什么节点会从矿工那里接受排除了许多交易的区块 —— 根据该节点自身的区块模板，这些交易预计会包含在区块内。有各种工具可以显示预期区块与实际区块的对比。Pieter Wuille 指出，不同节点的交易池会因为交易的传播而出现差异；无法实现一种强制指定区块内容的共识规则。

• ● 为什么每个人都说软分叉限制了现有的规则集？ Pieter Wuille 用在 taproot 和 segwit 软分叉激活期间添加的规则作为收紧共识规则的例子：

  • taproot 添加了 OP_1 <32 bytes>（taproot）输出遵守 taproot 共识规则的要求。
  • segwit 添加了 OP_{0..16} <2..40 bytes>（segwit）输出的花费必须遵守 segwit 共识规则的要求，并且还要求 segwit 前的输出有一个空的见证数据。

• ● 为什么默认的闪电网络通道限制设置为 16777215 sats？ Vojtěch Strnad 解释了 2^24 satoshi 限制的历史和大（wumbo）通道的动机，并指出 Optech 的 “大通道“ 主题页面有更多信息。

• ● 为什么 Bitcoin Core 使用祖先分数而不仅仅使用祖先费率来选择交易？ Sdaftuar 解释了该原因是性能优化：因为挖矿区块模板交易选择算法同时使用了祖先费率和祖先分数（参见等待确认＃2：激励措施）。

• [闪电多部分支付（MPP）协议如何定义每个部分的金额？]（https://bitcoin.stackexchange.com/a/117405） Rene Pickhardt 指出了多路径支付没有在协议中规定或由算法来选择每部分大小，同时给出了一些相关的支付拆分的研究。

版本和候选版本

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

• ● BTCPay Server 1.10.3是该自托管服务支付处理软件的最新版本。请参阅他们的博客文章，了解 1.10 分支中的主要功能。

重大的代码和文档变更：

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

• ● Core Lightning #6303 添加了一个新的 setconfig RPC，允许在不重新启动守护进程的情况下更改一些配置选项。

• ● Eclair #2701 开始记录通道对手提供的 HTLC 到达的时间和被结算的时间。这样可以从节点的角度来跟踪 HTLC 等待的时间。如果有很多 HTLC 或者有一些高价值的 HTLC 在长时间内等待，这可能表明当前有通道堵塞攻击在发生。跟踪 HTLC 的持续时间有助于检测甚至缓解此类攻击。

• ● Eclair #2696 更改了 Eclair 用户配置选用费率的方式。以前，用户可以用 区块目标 来指定要使用的费率，例如 “6” 表示 Eclair 将尝试在六个区块内确认交易。现在，Eclair 可接受“慢速”、“中速”和“快速”，并使用常量或区块目标将其转换为具体的费率。

• ● LND #7710 添加了插件（或守护程序本身）检索先前收到 HTLC 数据的能力。这对于盲化路由是必要的，并且可能被使用在各种通道阻塞对策以及其他未来功能的构想中。

• ● LDK #2368 允许接受由对等节点使用锚点输出创建的新通道，但需要控制程序来刻意选择接受每个新通道。这样做是因为正确结算锚点通道可能需要用户可访问一个或多个具有足够价值的未花费交易输出（UTXO）。LDK 作为一个无法知道用户钱包所控制的非闪电网络 UTXO 的库，使用此提示给控制程序一个机会来验证它是否具有必要的 UTXO。

• ● LDK #2367使普通 API 用户可访问锚点通道。

• ● LDK #2319允许对等节点创建一个 HTLC，该 HTLC 承诺支付的金额少于原始花费者应支付的金额，从而使对等节点能够保留差额作为自己的额外费用。这对于创建 JIT 通道非常有用 —— 当一个对等节点接收到一个 HTLC，但该 HTLC 的实际接受方还没有通道的时候。对等节点创建一个资金通道的链上交易，并在该通道内承诺 HTLC —— 但是在创建该链上交易时会产生额外的交易费用。如果接收方接受新通道并及时结算 HTLC，对等节点将通过收取额外费用来获得报酬。

• ● LDK #2120 添加了支持寻找通向使用盲化路径接收方的路径。

• ● LDK #2089 添加了一个事件处理器，使钱包可以容易地提高任何需要在链上结算的 HTLC 的费用。

• ● LDK #2077 重构了大量代码，以便以后更容易添加对双重充值通道的支持。

• ● Libsecp256k1 #1129 实现了 ElligatorSwift 技术，引入了一种 64 字节的公钥编码，该编码与随机数据在计算上无法区分。ellswift 模块提供了在新格式中编码和解码公钥的函数，以及便利的函数来生成新的均匀分布的随机密钥并执行基于 ellswift 编码的椭圆曲线 Diffie-Hellman 密钥交换（ECDH）。基于 ellswift 的 ECDH 是为了用于在第 2 版的 P2P 加密传输协议（BIP324）中建立连接。