本周的周报描述了一个新的管理型 joinpool 协议的提案，并总结了使用 Nostr 协议中继交易的想法。还包括我们关于交易池子规则限定系列的另一个条目，加上我们的常规部分总结了发布到 Bitcoin Stack Exchange 的重要问题和答案，列出了新的软件版本和候选版本，并描述了热门比特币基础设施项目的重大变更介绍。

新闻

  • ● 管理型 joinpool 协议的提案： 本周，Burak Keceli 在 Bitcoin-Dev 邮件列表上发布了 Ark 的想法，这是一种新的joinpool式协议，比特币的所有者可以选择使用交易对手作为特定时间段内所有交易的共同签署人。所有者可以在时间锁到期后单方面撤回他们在链上的比特币，或者在时间锁到期之前立即将比特币以无需信任的方式转移到交易对手方。

    与任何比特币用户一样，交易对手可以随时广播仅花费自己资金的链上交易。如果该交易的输出被用作将资金从所有者转移到交易对手的链下交易的输入，则除非链上交易在合理的时间内确认，否则链下转移将无效。在这种情况下，交易对手在收到已签名的链下交易之前不会签署他们的链上交易。这提供了从所有者到交易对手的无信任单跳、单向原子传输协议。Keceli 描述了这种原子传输协议的三种用途：

    • ● 混币： joinpool 中的多个用户都可以在交易对手的合作下，将他们当前的链下价值原子互换为等量的新链下价值。这可以快速执行，因为链上组件的故障只会取消互换，将所有资金返回到它们开始的地方。类似于一些现有的coinjoin实现所使用的盲化协议可以防止任何用户或交易对手确定哪个用户最终获得了哪些比特币。

    • ● 进行内部转账： 一个用户可以将他们的链下资金转移到具有相同交易对手的另一个用户。原子性确保收款人会得到他们的钱或付款方会收到退款。对于不信任支付方和交易对手方的接收方，他们需要等待与常规链上交易一样多的确认。

      Keceli 和一位评论员链接到 之前的研究，该研究描述了如何通过将零确认支付与诚实保证金配对来使得零确认支付与双花交易变得不经济，任何观察到双花交易的两个版本的矿工都可以申领诚实保证金。这可能允许收款人在几秒钟内接受付款，即使他们不信任任何其他人。

    • ● 支付 LN 发票： 如果交易对手知道秘密值，用户可以快速承诺将其链下资金支付给交易对手，从而允许用户通过交易对手支付 LN 类型的HTLC发票。

      与内部转账的问题类似，用户无法无需信任地接收资金，因此他们不应在付款收到足够数量的确认或由他们认为有说服力的诚实保证金担保之前透露秘密值。

    Keceli 说，目前可以使用 joinpool 成员之间的频繁交互在比特币上实施基础协议。如果有一个限制条款提案，比如：OP_CHECKTEMPLATEVERIFY、SIGHASH_ANYPREVOUT或者OP_CAT + OP_CHECKSIGFROMSTACK被实施，joinpool 的成员将只需要在参与 coinjoin、付款或刷新其链下资金的时间锁时与交易对手进行交互。

    每个 coinjoin、支付或刷新都需要在链上交易中发布承诺，尽管基本上无限数量的操作都可以捆绑在同一个小交易中。为了让操作能够快速完成，Keceli 建议大约每五秒进行一次链上交易，这样用户就不需要等待超过这个时间。每笔交易都是独立的，也就不可能在不破坏承诺或需要前几轮涉及的所有用户的参与下，通过使用手续费替换来合并来自多个交易的承诺。因此，一个交易对手每年可能需要确认超过 630 万笔交易，尽管单笔交易都相当小。

    在邮件列表中发布的有关协议的评论包括：

    • ● 更多文件的请求： 至少有两位受访者要求提供有关系统如何工作的额外文件，因为邮件列表中提供的高级描述很难分析。此后，Keceli 开始发布规范草案。

    • ● 担心与 LN 相比接收速度较慢： 有几个人指出，在最初的设计中，无法在不等待足够数量的确认的情况下从 joinpool（链上或者链下）获得无需信任的支付。这可能需要数小时，而目前许多 LN 付款不到一秒即可完成。即使有诚实保证金，LN 的平均速度也会更快。

    • ● 担心链上占用空间很大： 一个回复指出，每五秒进行一次交易，大约 200 个这样的交易对手将消耗每个区块的整个空间。另一个回复假设交易对手的每笔链上交易的大小大致相当于 LN 通道开放或合作关闭交易的大小，因此拥有 100 万用户的交易对手每年创建 630 万笔链上交易将使用相当于每个用户每年平均打开或关闭 6.3 个通道的空间；因此，LN 的链上成本可能低于使用这种交易对手，直到它达到大规模采用。

    • ● 对大型热钱包和资本成本的担忧： 一个回复考虑到，交易对手需要保持一定数量的比特币（可能在热钱包中）以应对用户在不久的将来可能花费的金额。在当前的设计方案下，在花费一段时间后，交易对手可能需要等待长达 28 天才能收回他们的比特币。如果交易对手对其资本收取了每年 1.5% 的低利率，那么每次涉及交易对手的交易（包括coinjoin、内部转账和LN支付）的金额上将相当于 0.125% 的费用。相比之下，撰写时可获得的公共统计数据(由1ML收集)显示，LN 转账每跳中位数费率为 0.0026％，几乎低了 50 倍。

    列表上的几条评论也对这个提议感到兴奋，并期待看到 Keceli 和其他人探索管理型 joinpools 的设计空间。

  • ● 通过 Nostr 进行交易中继： Joost Jager 在 Bitcoin-Dev 邮件列表上发帖，请求对 Ben Carman 使用 Nostr协议中继交易的想法提供反馈，这些交易可能无法在提供中继服务的比特币全节点的 P2P 网络上很好地传播。

    特别是，Jager研究了使用 Nostr 中继交易包的可能性，例如通过将其与支付足够高的费用以补偿其祖先的费用不足的后代交易捆绑在一起，以低于最低接受值的费率中继祖先交易。这使得 CPFP费用提升更加可靠和高效，这是 Bitcoin Core 开发人员一直致力于为比特币 P2P 网络实现的一项称为包中继的功能。审查包中继的设计和实现的一个挑战是确保新的中继方法不会针对单个节点和矿工（或通常对网络）创建任何新的拒绝服务（DoS）漏洞。

    Jager指出，Nostr 中继有能力轻松使用来自P2P中继网络的替代类型的 DoS 保护，例如需要少量付款来中继交易。他建议，即使恶意交易或包可能导致浪费少量节点资源，允许包中继或其他替代事务的中继也会变得切实并可行。

    Jager 的帖子中链接了一个指向他演示该功能的视频。截至撰写本文时，他的帖子只收到了一些回复，尽管它们都是积极的。

等待确认#3：竞价区块空间

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

上周我们提到交易为所用的区块空间支付费用，而不是按照所转移的金额支付费用，并确定矿工将优化他们的交易选择以最大化收取费用。因此，当找到一个块时，只有那些位于交易池头部的交易才会得到确认。在这篇文章中，我们将讨论让手续费花得最值的实用策略。让我们假设我们有一个不错的费率估算来源——我们将在下周的文章中更多地讨论费率估算。

在构建交易时，交易的某些部分比其他部分更灵活。每笔交易都需要头部字段，收款人输出由正在进行的付款决定，并且大多数交易都需要找零输出。发送方和接收方都应该更喜欢区块空间高效的输出类型，以减少未来花费交易输出的成本，但在输入/钱币选择期间，更改交易的最终组成和重量的空间最大。由于交易按费率[费率/重量]竞争，较轻的交易只需更低的费用就能达到相同的费率。

一些钱包，例如 Bitcoin Core 钱包，尝试组合输入以避免设置找零输出。避免找零可以节省现在输出的重量，还可以节省以后花费找零输出的未来成本。不幸的是，除非钱包拥有大量不同金额的大型 UTXO 池，否则这种输入组合几乎不存在。

较新的输出类型比旧输出类型更节省区块空间。例如，花费 P2TR 输入产生的重量不到 P2PKH 输入的 2/5。(使用我们的交易规模计算器试试吧！)对于多重签名钱包，最近定稿的 MuSig2 方案和 FROST 协议通过允许多重签名功能以看起来像单签名输入的方式编码，节省了许多费用。特别是在区块空间需求飙升的时代，使用较新的输出类型的钱包本身就可以节省大量费用。

Overview of input and output weights

聪明的钱包根据费率调整其选择策略：在高费率下，它们使用很少的输入和较新的输入类型来让输入集的重量尽可能低。始终选择最轻的输入集将局部地最小化当前交易的成本，但也会将钱包的 UTXO 池磨成小碎片。这可能会让用户在日后的高手续费率环境下也不得不选择较重的输入集。因此，对钱包来说，具有先见之明的做法是，如果预期日后会出现区块空间的需求高峰，就趁手续费率的低谷选择更多和更重的输入、将资金整合进数量更少的新型输出。

大容量钱包通常会将多个付款批处理到单个交易中，以减少每一笔支付的交易重量。批处理避免了头字节的开销和每次付款的找零输出，所有支付共同分摊同一份固定开销。即使只是批量处理几笔付款，也可以快速降低每次付款的成本。

Savings from payment batching with P2WPKH

但是，即便许多钱包会错误估计手续费(因此超额支付(overpayment))，在出块缓慢或交易提交量激增的时候，有时交易也会迟迟得不到确认。在这些情况下，发送方或接收方可能希望再次提高交易的确认优先级。

用户通常有两种工具可以提高交易的优先级，即“子为父偿(CPFP)”和“手续费替换(RBF)”。在 CPFP 中，用户花费其交易输出来创建高费率的子交易。正如上周的帖子所描述的那样，矿工被激励将父交易选入区块，以便包括手续费高的子交易。一笔交易的任何收款者均可利用 CPFP，因此接收方和发送方（如果他们创建了找零输出）都可以利用它。

在 RBF 中，发送者制作更高手续费的交易以替换原版交易。替换交易必须重用原版交易中的至少一个输入，以确保与原版交易冲突，并且区块链中只能包含两个交易中的一个。通常，这样的替换交易会保留原版交易的付款，但发送者也可以将替换交易中的资金重新定向，或者在替换时将多个交易的付款合并为一个。正如上周的帖子所述，节点驱逐原版交易，以支持更具激励相容的替换交易。

虽然区块空间的需求和生产都不在我们的控制范围内，但钱包可以使用许多技术来有效地竞标区块空间。钱包可以通过消除找零输出、花费原生的隔离见证输出以及在低费率环境中对其 UTXO 池进行碎片整理，来创建更轻的交易，以节省费用。支持 CPFP 和 RBF 的钱包也可以从保守的费率开始，然后在需要时使用 CPFP 或 RBF 更新交易的优先级。

Bitcoin Stack Exchange 精选问答

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

版本和候选版本

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

  • ● Bitcoin Core 25.0是 Bitcoin Core 下一个主要版本。该版本添加了一个新的scanblocksRPC，简化了bitcoin-cli的使用，为finalizepsbtRPC 添加了miniscript支持，使用blocksonly配置选项减少了默认内存使用，并在启用致密区块过滤器时加快了钱包重新扫描的速度——以及许多其他新功能、性能改进和错误修复。有关详细信息，见版本文档。

重大的代码和文档变更：

本周的重大变更有：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 #27469在使用一个或多个钱包时加速了初始区块下载（IBD）。通过此更改，如果区块是在钱包的出生日期（钱包中记录的创建日期）之后开采的，则只会扫描与特定钱包匹配的交易。

  • ● Bitcoin Core #27626允许要求我们的节点在高带宽模式下提供致密区块中继的对等方从我们向他们发布的最新块发出最多三个交易请求。即使我们最初没有向它们提供致密区块，我们的节点也会响应请求。这允许从其他对等方之一接收致密区块的对等节点向我们请求任何丢失的交易，如果另一个对等节点没有响应，这可以提供帮助。这可以帮助我们的对等方更快地验证区块，这也可以帮助他们在时间关键型功能（如挖矿）中更快地使用它。

  • ● Bitcoin Core #25796添加了一个新的descriptorprocesspsbt，可用于更新PSBT，这些信息将有助于以后签名或最终确定。提供给 RPC 的描述符将用于从交易池和 UTXO 集中检索信息(并且，如果可用，则在使用txindex配置选项启动节点时完成已确认的事务)。然后，检索到的信息将用于填写 PSBT。

  • ● Eclair #2668阻止 Eclair 试图支付比成功解析该 HTLC 所获得的价值更多的费用来申领链上 HTLC。

  • ● Eclair #2666允许接收 HTLC 的远程节点接受它，即使接受它需要支付的交易费用会将节点的余额减少到最低通道储备以下。通道储备的存在是为了确保节点在试图关闭处于过时状态的通道时至少会损失少量资金，从而阻止他们盗窃的企图。但是，如果远程节点接受 HTLC，一旦成功，HTLC 将向他们付款，那么无论如何，他们将面临比储备金更多的风险。如果不成功，他们的余额将恢复到之前的金额，该金额将高于储备金。

    这是对资金滞留问题的缓解措施，资金滞留问题发生在一笔付款的手续费承担方需要支付比其当前可用余额更多的价值时，即使他们可能是接收付款的一方，也会发生这种情况。有关此问题的先前讨论，见周报 #85.

  • ● BTCPay Server 97e7e开始为payjoin支付设置BIP78minfeerate(最小费率)参数。另请参阅导致此提交的错误报告。

  • ● BIPs #1446对比特币相关协议的schnorr 签名的BIP340规范进行了小改动和一些补充。此更改允许对消息进行任意长度的签名；以前版本的 BIP 要求消息正好为 32 个字节。描述对 Libsecp256k1 库的相关更改请见 周报 #157。此更改对共识应用程序中 BIP340 的使用没有影响，因为与taproot和tapscript (分别为，BIPs341 and 342)一起使用的签名使用 32 字节消息。

    新增内容描述了如何有效地使用任意长度的消息，推荐了如何使用散列标记前缀，并提供了在不同域中使用相同的密钥（例如签署交易或签署纯文本消息）时提高安全性的建议。