本周的周报介绍了一项开始测试 HTLC 背书的提案，征求有关闪电服务提供商（LSP）拟议规范的反馈意见，讨论了在使用双重充值时开放零配置通道的挑战，研究了一种高级 payjoin 交易应用程序的建议，并提供了 Bitcoin Core 开发人员最近的面对面会议摘要的链接。本周的周报还包括了有关交易中继和交易池包容性政策的新系列的第一部分，以及我们定期发布的新版本和候选发布版本（包括 libsecp256k1 的安全版本）的公告，以及描述流行的比特币基础设施软件的显着变化。

新闻

  • ● 测试 HTLC 背书： 几周前，Carla Kirk-Cohen 和 Clara Shikhelman 在 Lightning-Dev 邮件列表上发布了他们和其他人计划采取的下一步行动，以测试 HTLC 背书的想法（请参见 Newsletter＃239），作为缓解通道阻塞攻击 的一部分。最值得注意的是，他们提供了一个简短的提议规范，可以使用实验标志进行部署，防止其部署对与非参与节点的交互产生任何影响。

    实验者一旦部署，就应该更容易回答这个想法的建设性批评之一，即实际上有多少转发付款会从该方案中获得提升。如果闪电网络的核心用户经常通过许多相同的路由相互发送支付，并且如果信誉系统按计划运行，那么该核心网络将更有可能在通道阻塞攻击期间保持运行。但是，如果大多数消费者很少发送付款（或者很少发送他们最关键的付款类型，例如大额付款），那么他们将没有足够的互动来建立声誉，或者声誉数据将远远落后于网络的当前状态（使其变得不那么有用，甚至允许滥用声誉）。

  • ● 请求对 LSP 拟议规范的反馈：Severin Bühler 在 Lightning-Dev 邮件列表中发布了一个对闪电服务提供商 (LSP) 与其客户（通常是非转发闪电节点）之间互操作性的两项技术规范的反馈请求。第一个规范描述了一个允许客户从 LSP 购买通道的 API。第二个规范描述了一个用于设置和管理即时 (JIT) 通道的 API，这些通道以虚拟支付渠道的形式开始；当收到对虚拟通道的第一笔付款时，LSP 广播一个交易，该交易将在确认后将通道锚定在链上（使其成为常规通道）。

    在回复中，开发人员 ZmnSCPxj 写到支持 LSP 的开放规范。他指出，它们使客户可以轻松连接到多个 LSP，这将防止供应商锁定并改善隐私。

  • ● 双重充值对零配置通道的挑战：Bastien Teinturier 在 Lightning-Dev 邮件列表中发布，关于在使用双重充值协议。零配置通道甚至可以在通道打开交易确认之前使用；在某些情况下这是无需信任的。双重充值通道是使用双重充值协议创建的通道，其中可能包括开放交易包含通道双方输入的通道。

    只有当一方控制公开交易的所有输入时，零配置才是无信任的。例如，Alice 创建公开交易，在通道中给 Bob 一些资金，Bob 尝试通过 Alice 将这些资金花给 Carol。 Alice 可以安全地将付款转发给 Carol，因为 Alice 知道她控制着最终被确认的公开交易。但是，如果 Bob 在公开交易中也有输入，他可以获得冲突交易确认，这将阻止公开交易确认——防止 Alice 因她转发给 Carol 的任何钱而得到补偿。

    允许通过双重充值打开零配置通道的几个想法已被讨论，尽管在撰写本文时似乎没有一个令参与者满意。

  • ● 高级 payjoin 应用：Dan Gould 在 Bitcoin-Dev 邮件列表中发布了关于使用 payjoin 协议实现不仅仅是发送或接收简单付款的一些建议。我们发现最有趣的两个建议是交易合并（transaction cut-through）的版本。这是一个改善隐私、提高可扩展性和降低费用成本的老想法：

    • ● 付款转发：Alice 不是向 Bob 付款，而是向 Bob 的供应商 (Carol) 付款，从而减少他欠她的债务（或预付预期的未来账单）。

    • ● 批量付款转发：Alice 不是向 Bob 付款，而是向 Bob 欠款（或想与之建立信用）的几个人付款。 Gould 的例子考虑了一个有稳定存款和取款流的交易所； payjoin 允许在可能的情况下用新存款支付提款。

    这两种技术都允许将至少两笔交易减少到一笔交易中，从而节省大量的块空间。当使用批量付款时，空间节省可能会更大。从原始接收者（例如 Bob）的角度来看更好，原始支出者（例如 Alice）可能会支付全部或部分费用。除了节省空间和费用之外，从区块链中删除交易并将接收和支出等操作结合起来，使得区块链监控组织更难以可靠地追踪资金流向。

    在撰写本文时，该帖子尚未在邮件列表中收到任何讨论。

  • ● Bitcoin Core 开发人员面对面会议摘要：几位从事 Bitcoin Core 工作的开发人员最近开会讨论了该项目的各个方面。会议期间的几次讨论的笔记已经发表。讨论的主题包括模糊测试、假设UTXO、ASMap、静默支付、libbitcoinkernel、重构（或不重构）和包中继。还讨论了我们认为值得特别关注的另外两个主题：

    • ● 交易池聚类总结了一项重大重新设计交易及其元数据如何存储在 Bitcoin Core 交易池中的建议。这些说明描述了当前设计的许多问题，提供了新设计的概述，并提出了一些挑战和所涉及的权衡。设计的描述和演示文稿中幻灯片的副本随后已发布。

    • ● 项目元讨论总结了关于项目目标的各种讨论，以及如何在面临许多内部和外部挑战的情况下实现这些目标。一些讨论已经导致项目管理的实验性变化，例如在版本 25 之后的下一个主要版本采用更加以项目为中心的方法。

等待确认 #1: 我们为什么需要一个交易池？

关于交易中继、交易池接纳和挖矿交易选择的限定版每周系列内容的第一部分——包括为什么 Bitcoin Core 有着比共识允许的更严格的策略，以及钱包如何最有效地使用该策略。

比特币网络上的许多节点将未确认的交易存储在一个内存池或称之为 交易池（mempool）。该缓存是每个节点的重要资源，使得点对点的交易中继网络成为可能。

参与交易中继的节点稳步而非陡然地下载和验证区块。每隔约 10 分钟发现一个区块时，没有交易池的节点就会出现带宽峰值，随之而来的是验证每笔交易的计算密集期；另一方面，具有交易池的节点通常已经看到了区块的所有交易并将它们存储在它们的内存池中。使用“致密区块中继，这些节点只需下载一个区块头和 shortid，就可以使用其交易池中的交易来重建区块。与区块的大小相比，用于中继致密区块的数据量很小。验证交易也快得多：节点已经验证（并缓存）了签名和脚本，计算了时间锁要求，并已经出于必要、从磁盘加载了相关的 UTXO。该节点还可以迅速将区块转发给其他节点，从而显着提高网络范围内的区块传播速度、降低出现陈旧区块的风险。

交易池也可用于构建独立的费用估算器。区块空间市场是收费拍卖，保留交易池可以让用户更好地了解其他人在竞标什么以及过去哪些竞标成功了。

然而，没有“唯一交易池”这样的东西——每个节点可能会收到不同的交易。向一个节点提交交易并不一定意味着它已经到达矿工手中。一些用户发现这种不确定性令人沮丧，并想知道，“我们为什么不直接向矿工提交交易呢？”

设想一种比特币网络，其中所有交易都直接从用户发送到矿工。人们可以通过要求少数实体记录与每笔交易对应的 IP 地址来审查和监视金融活动，并拒绝接受任何符合特定模式的交易。这种类型的比特币有时可能更方便，但会缺少一些比特币最有价值的特性。

比特币的抗审查性和隐私性来自于它的点对点网络。为了中继交易，每个节点都可以连接到一些匿名的对手节点集，每个对手节点都可以是矿工或与矿工有联系的人。此方法有助于混淆交易源自哪个节点，以及哪个节点可能负责确认它。希望审查特定实体的人可能会针对矿工、热门交易所或其他中心化提交服务，但很难完全阻止任何事情。

未确认交易的普遍可用性也有助于最大限度地降低成为区块生产者的进入成本——对被选择（或被排除）的交易不满意的人可能会立即开始挖矿。将每个节点视为交易广播的平等候选者，可避免给予任何矿工获取交易及其费用的特权。

总之，交易池是一种非常有用的缓存，它允许节点随时间分配区块下载和验证的成本，并让用户获得更好的费用估算。在网络层面，交易池支持交易分发和区块中继网络。当每个人都在矿工将它们包含在区块中之前看到所有交易时，所有这些好处最为明显——就像任何缓存一样，交易池在“火热”时最有用，并且必须限制其大小以适应内存。

下周本节将探讨使用激励相容性作为判断哪些交易将保留在交易池中的最有用的指标。

新版本和候选版本

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

  • ● Libsecp256k1 0.3.2 是针对将 libsecp 用于 ECDH 且可能使用 GCC 13 或更高版本编译的应用程序的安全版本。正如作者所描述的，新版本的 GCC 试图优化设计为在固定时间内运行的 libsecp 代码，从而在一些特定情况下可以执行侧信道攻击。值得注意的是，Bitcoin Core 不使用 ECDH，因此不受影响。目前正在进行的工作是尝试检测未来对编译器的更改何时可能导致类似问题，从而允许提前进行更改。

  • ● Core Lightning 23.05rc2 是此闪电网络实现的下一版本的候选发布版本。

  • ● Bitcoin Core 23.2rc1 是 Bitcoin Core 先前主要版本的维护版本的候选版本。

  • ● Bitcoin Core 24.1rc3 是对 Bitcoin Core 当前版本维护发布的一个候选发布版本。

  • ● Bitcoin Core 25.0rc2 是 Bitcoin Core 下一个主要版本的候选发布版本。

重大的代码和文档变更

本周出现重大变更的有：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 #26076 更新显示公钥派生路径的 RPC 方法，现在使用 h 而不是单引号 ' 来指示强化的派生步骤。请注意，这会更改描述符校验和。使用私钥处理描述符时，使用与生成或导入描述符时相同的符号。对于老钱包 getaddressinfo 中的 hdkeypath 字段和钱包转储的序列化格式保持不变。

  • ● Bitcoin Core #27608 将继续尝试从一个对等节点下载一个区块，即使另一个节点提供了该区块。 Bitcoin Core 将继续尝试从声称拥有它的节点下载该区块，直到接收到的其中一个区块已写入磁盘。

  • ● LDK #2286 允许为本地钱包控制的输出创建和签署 PSBTs。

  • ● LDK #1794 开始添加对双重充值的支持。该支持从用于双重充值的交互式充值协议所需的方法开始。

  • ● Rust Bitcoin #1844 使 BIP21 URI 小写的模式，即 bitcoin:。尽管 URI 架构规范 (RFC3986) 表示该架构不区分大小写，但测试表明，当传递大写 BITCOIN: 的 URI 时，某些平台不会打开那些只处理 bitcoin: 的应用。如果能正确处理大写字母会更好，因为它允许创建更有效的 QR 码（参见 Newsletter #46）。

  • ● Rust Bitcoin #1837 添加了一个生成新私钥的功能，简化了以前需要更多代码才能完成的工作。

  • ● BOLTs #1075 更新规范，以便节点在收到来自对等节点的警告消息后不应再断开与它的连接。