本周的周报介绍了关于比特币和相关协议的零知识证明有效性证据的研究。此外，还有我们关于交易池规则的限定系列，以及我们的常规栏目：客户端和服务的更新、软件的新版本和候选版本，以及热门的比特币基础设施项目的更新。

新闻

  • ● 使用零知识证明有效性证据压缩状态：Robin Linux 在 Bitcoin-Dev 邮件组中发帖，公开了他跟 Lukas George 联合撰写的、使用有效性证据来减少客户端（为免信任地验证系统未来的动作）所需下载的状态数量的论文。这是他们第一次将自己的系统应用在比特币上。他们报告称已经有了一个原型，证明了在区块头链条中累积的工作量证明，而且允许一个客户端验证某一个区块头是这个链条的一部分。这使得客户端可以通过接收多个证据来确定哪条链是累积了最多工作量证明的。

    他们还有一个未达最优状态的原像，证明比特币区块链上的所有交易的状态转换都遵守了货币规则（例如：一个新区块产生了多少新比特币、每一个非 coinbase 的交易不能创建超过所花费价值的 UTXO、矿工得到的手续费在被花费的 UTXO 和被创建的 UTXO 的价值差额以内）。收到这样的证据以及最新 UTXO 集拷贝的客户端可以验证这个集合是准确和完整的。他们把这个证据称为 “assumevalid 证据”，这个名字来源于 Bitcoin Core 中的一个特性：你可以选择跳过一些较老的区块的交易脚本验证，因为你认为网络中的许多贡献者都已经成功验证了这些区块。

    为了尽可能降低他们的证据的复杂性，他们使用了一个版本的 utreexo，并用上了一个为他们的系统而优化的哈希函数。他们独自声称，结合他们的证据与 utreexo，客户端只需下载非常少量的数据，几乎马上就可以变成一个全节点。

    至于他们的原型的效用，他们的说法是：“我们已经实现了区块头链证据以及 assumevalid 状态证据，作为原型。前者是是可行的，但后者依然需要性能优化，以证明区块的大小在合理范围内”。他们也在开发完整区块的证据，包括脚本验证，但他们也说，需要至少 40 倍的速度提升，才能让这样的证据有实用价值。

    除了比特币区块链的状态压缩，他们还提出了一套协议，可以用在基于 “客户端验证” 的代币协议中，类似于 Lightning Labs 所提出的 Taproot Assets 以及 RGB 协议的一些用途（见周报 #195和周报 #247）。当 Alice 给 Bob 发送一些某代币的时候，Bob 需要验证这些代币在此前的每一次转账，直至这种代币的创生。在理想的情况下，这个历史的体量会随着代币转移的次数而线性上升。但如果 Bob 希望给 Carol 一些这种代币，而且数量比他从 Alice 那里得到的更多，他就需要合并从 Alice 那里收到的这种代币以及从别处收到的这种代币。Carol 将需要验证两部分历史：一部分表示一些数额经由 Alice 到达 Bob；另一部分表示另一些数额经由别处到达 Bob 。这叫做 “合并（merge）”。如果合并经常发生，需要被验证的历史的体积会接近于任意两位用户之间的每一次代币转移的历史体积。相比之下，在比特币中，每一个全节点都验证每一个用户提起的每一笔交易；而在使用客户端验证的代币协议中，这并不是严格要求的，但如果合并很常见，则也会像比特币一样。

    这意味着，一个可以压缩比特币状态的协议，也可以改造成压缩代币历史的协议，即使合并经常发生也没关系。论文的作者介绍了他们会如何实现这样的协议。他们的目标是产生一种证据，证明以前的每一次代币转移到遵循了这种代币的规则，包括使用他们为比特币生成的证据，以证明每一次代币转移都锚定到了比特币区块链。然后，Alice 就可以转移代币给 Bob，并给他一个简短的、体积恒定的有效性证据；Bob 可以验证这个证据，以知晓以前的转账发生在类某个区块高度、最终支付给了他的代币钱包，并给了他完全的控制权。

    虽然这篇论文经常提到可以进行的额外的研究和开发，我们发现，这是向着一个比特币的开发者们梦想了十多年的特性，作出的令人鼓舞的进步。

等待确认 #2：激励

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

本栏目在上周提到，交易池（mempool）是未确认交易的缓存空间，它为用户提供了一种去中心化的、向矿工发送交易数据的方法。但是，矿工没有义务确认这些交易；只包含了一笔 coinbase 交易的区块也是共识上有效的区块。用户可以通过提高输入的价值而不改变输出的总价值 —— 矿工能够获取两端的差额作为交易 手续费 —— 来吸引矿工打包自己的交易。

虽然交易手续费在传统的金融系统中很常见，但刚接触比特币的用户可能经常觉得惊讶，这些手续费不是按支付额的比例收取的，而是根据交易的重量（weight）收取的。也就是说，区块空间才是限制因素，流动性并不是。手续费率 通常以 聪/vB（虚拟字节）来衡量。

共识规则限制了每个区块可用于打包交易的空间。这个限制使得区块广播到整个网络的时间低于出现区块的间隔，从而降低了出现 “过时区块（stale blocks）” 的风险。它也帮助限制了区块链和 UTXO 集的体积增长，这两者都直接构成了启动和维护一个全节点的成本。

因此，作为这个未确认交易的缓存的角色的一部分，交易池也协助了无弹性的区块空间的公开拍卖：在正常运行的时候，拍卖会遵循自由市场的原理，即，完全基于手续费，而非跟矿工的个人关系，来决定交易打包的优先级。

为一个区块（有自身的总重量限制和签名操作数量限制）选择交易、同时最大化手续费，是一个 “NP 困难问题”。这个问题会因为交易之间的关联而变得更加复杂：打包一笔高费率的交易，可能需要同时打包一笔低费率的父交易。反过来说，打包一笔低费率的交易，可能会开启打包高费率子交易的机会。

Bitcoin Core 客户端的交易池会为每一笔交易及其祖先交易计算手续费率（称为 “祖先手续费率”），缓存这个结果，然后使用一种 “贪婪区块模板建构算法”。它会按 “祖先分数”（在祖先手续费率和单体交易手续费率两者间取小值）为交易池排序，然后按顺序选出祖先交易包、更新剩余交易的祖先手续费，并对信息加权。这套算法在性能和获利能力之间取得了一个平衡，但并不一定能产生最优的结果。它的效力可以通过限制单体交易和祖先交易包的体积来提高 —— Bitcoin Core 将它们分别限制在 40 0000 重量单位和 40 4000 重量单位。

类似地，可以计算出一个 后代分数 并用来选择要逐出交易池的交易包，因为逐出自身低手续费率但具有高手续费率后代的交易可能会错失好处。

交易池验证在处理花费相同输入的交易（即，重复花费或者说冲突交易）时也会用到手续费和手续费率。节点不会按先到先得的规则保留先收到的那一笔交易，而是会根据一组规则来确定哪一笔交易更加激励兼容，然后保留下来。这个行为叫做 “手续费替换（Replace by Fee）”。

矿工会最大化手续费，这符合直觉，但为什么一个不挖矿的节点也要实现这些规则呢？就像上周本栏目所说的，不挖矿节点的交易池的效用，是由它跟矿工的交易池的相似性决定的。因此，即使一个节点从不尝试使用其交易池中的内容产生区块，他们也愿意保存最为激励兼容的交易。

虽然没有共识规则要求交易支付手续费，但手续费和手续费率在为比特币网络中扮演着重要角色，它是一种 “公平的” 解决区块空间竞争的办法。矿工使用手续费率来评估可取程度、处理驱逐和冲突，而不挖矿的节点也参照这种行为，以尽可能提高自己的交易池的效用。

区块空间的稀缺性，产生了降低交易体积的压力，并鼓励开发者构造更有效率的交易。下周的专栏中，我们会探索链上交易节约手续费的实用策略和技术。

服务和客户端软件的变更

在这个月度栏目中，我们会标出比特币钱包和服务的有趣更新。

  • ● Passport 固件 2.1.1 发布：Passport 硬件签名设备的最新的固件支持发送到 taproot 地址、BIP85 特性，并提升了处理 “部分签名的比特币交易（PSBTs）” 和多签名配置的能力。

  • ● MuSig 钱包 Munstr 发布：beta 版的 Munstr 软件 软件使用了 nostr 协议，以协助签名 MuSig 多签名交易所需的通信。

  • ● CLN 插件管理器 Coffee 发布：Coffee 是一个 CLN 闪电客户端的插件管理器，改进了 CLN 插件 的安装、配置、依赖项管理和升级。

  • ● Electrum 4.4.3 发布：最新的 Electrum 软件包含 “钱币控制（coin control）” 上的提升，一个 UTXO 隐私性分析工具，并支持 “短通道标识符（SCID）”，还有别的修复和升级。

  • ● Trezor Suite 添加 coinjoin 支持：Trezor Suite 软件宣布支持使用 zkSNACK 协调员的 coinjoins 功能。

  • ● Lightning Loop 默认使用 MuSig2 协议：Lightning Loop 现在开始默认使用 MuSig2 作为互换协议，以获得更低的手续费和更好的隐私性。

  • ● Mutinynet 宣布推出新的用于测试的 signet：Mutinynet 是一个定制化的 signet，出块时间为 30 秒，并提供了测试用的基础设施，包括区块浏览器、水龙头、测试用的闪电节点和运行在网络中的 LSP。

  • ● Nunchuk 添加了钱币控制和 BIP329 支持：Nunchuk 的最新安卓和 iOS 版本添加了钱币控制 功能以及BIP329钱包标签导出特性。

  • ● MyCitadel 钱包添加了强化后的 miniscript 支持：v1.3.0 版本添加了包括时间锁在内的更复杂的 miniscript 功能。

  • ● Coldcard 的 Edge 固件发布：Coinkite 宣布 为 Coldcard 硬件签名设备推出实验性的固件，专门让钱包开发者和有能力的用户实验更新的特性。最初的 6.0.0.X 版本包括了 taproot 密钥路径花费功能，tapscript 多签名花费功能以及 BIP129 支持。

新版本和候选版本

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

重大的代码和说明书变更

本周出现重大变更的有：Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals (BIPs) 和 Bitcoin Inquisition。

  • ● Bitcoin Core #27021 加入了一个接口，可以计算将一个输出的未确认祖先交易的手续费率提升到一个给定的数值需要多大的代价，这个数值称为 “费用赤字”。当钱币选择考虑在某个费率下使用某一个输出时，其祖先交易在当前费率下的费用赤字会计算出来，然后从该输出的实际价值中扣除。这会使钱包不愿意在其它可花费的输出可用时选择花费这样的高代价输出。在一个后续的 PR，这个接口也会被用于帮助钱包支付额外的手续费（也即 “手续费追加额”） —— 在不得不使用这样的高代价输出的时候 —— 以保证新的交易支付了用户所要求的实质手续费率。

    这个算法可以通过计算一个未确认的 UTXO 的所有未确认的交易集群、再减去应该会在目标费率进入区块的交易，估算出需要为任意的祖先集合追加的手续费。另一种方法则提供了多个未确认输出的聚合手续费追加额，以修正祖先交易可能重叠所带来的影响。

  • ● LND #7668 添加了能够在开启通道时附加最多达 500 字符的私密文字、并允许运营者日后检索这些信息，这也许能帮助运营者回忆开启这条通道的目的。

  • ● LDK #2204 添加了设定定制化 “特性位（feature bits）” 的功能，可以向对等节点宣布，也可以在尝试解析对等节点的公告时使用。

  • ● LDK #1841 实现了之前添加到闪电网络规范中的一个安全建议（见周报 #128）：当节点在使用 “锚点输出” 时，不应该在交易需要迅速确认时尝试批量处理由多方控制的输入。这样能够防止其他人推迟你的交易确认。

  • ● BIPs #1412 更新了 BIP329 钱包标签导出格式，添加了一个字段用于存储密钥的初始信息。此外，这个规范现在建议标签的长度的限制为 255 字符。