本周的周报关注了区块传播时间如何影响矿工收益的分析，并描述了解决多方共享资金协议的新方法。此外还包括我们的常规部分：描述服务和客户端软件的最新变更，以及总结对热门比特币基础设施软件的重大合并。

新闻

  • ● 通过传播延迟和挖矿中心化建模废块率： Antoine Poinsot 在 Delving Bitcoin 上发布了关于建模废块率以及区块传播时间如何作为算力函数影响矿工收益的内容。他建立了一个基础情况场景，其中所有矿工都表现得很现实（使用默认的 Bitcoin Core 节点）：如果他们收到一个新区块，他们会立即开始在其上挖矿并发布它。在传播时间为零的情况下，这将导致收益与其算力份额成正比。

    在他的均匀区块传播模型中，他概述了区块变废的两种情况：

    1. 另一个矿工在这个矿工之前找到了区块。所有其他矿工首先收到了竞争矿工的区块并开始在其上挖矿。然后这些矿工中的任何一个都可以基于收到的区块找到第二个区块。

    2. 另一个矿工在这个矿工之后找到区块。它立即开始在其上挖矿。后续区块也是由同一个矿工找到的。

    Poinsot 指出，在这些情况之间，第一种情况更可能导致区块变废。这表明矿工可能更关心更快地听到其他人的区块，而不是发布自己的区块。他还建议，第二种情况的概率随着矿工中心化显著增加。虽然在两种情况下概率都会随着矿工算力的增加而增加，但 Poinsot 想要计算增加了多少。

    为此，他创建了以下两个模型。

    其中 h 是网络算力份额，s 是网络其余部分在它之前找到竞争区块的秒数，H 是网络上代表其分布的算力集合。

    情况 1 的模型： 另一个矿工之前找到区块的概率图示

    情况 2 的模型： 另一个矿工之后找到区块的概率图示

    他继续展示了矿工区块变废概率作为传播时间函数的图表，给定算力的设定分布。这些图表显示了更大的矿工在传播时间越长时获得的收益显著增加。

    例如，一个拥有 5EH/s 的挖矿操作可以预期 9100 万美元的收益，如果区块需要 10 秒传播，收益将增加 10 万美元。请记住，9100 万美元是收益而不是利润，所以增加的 10 万美元收益将对矿工的净利润产生更大的影响。

    在图表下方，他提供了生成图表的方法，并链接到他的模拟，该模拟证实了用于生成图表的模型的结果。

  • ● 协作关闭的私钥移交： ZmnSCPxj 在 Delving Bitcoin 上发布了关于私钥移交的内容，这是一种当之前由两方拥有的资金需要退还给单个实体时协议可以实现的优化。这种增强需要 taproot 和 MuSig2 支持才能以最高效的方式工作。

    这种协议的一个例子是 HTLC，其中一方在原像被揭示时向另一方付款，创建一个需要双方签名的退款交易。私钥移交将允许实体在原像被揭示后简单地将临时私钥移交给另一方，从而给接收方完全和单方面的资金访问权。

    实现私钥移交的步骤是：

    • 在建立 HTLC 时，Alice 和 Bob 各自交换一个临时和一个永久公钥。

    • HTLC taproot 输出的密钥路径花费分支被计算为 Alice 和 Bob 临时公钥的 MuSig2。

    • 在协议操作结束时，Bob 向 Alice 提供原像，Alice 反过来将临时私钥移交给他。

    • Bob 现在可以推导出 MuSig2 和的组合私钥，获得对资金的完全控制。

    这种优化带来了一些特殊的好处。首先，在链上费用突然飙升的情况下，Bob 能够在没有另一方协作的情况下 使用手续费替换（RBF） 交易。这个功能对协议开发者特别有用，因为他们不需要在简单的概念证明中实现 RBF。其次，接收方能够将声明资金的交易与任何其他操作批处理。

    私钥移交限于要求剩余资金完全转移给单个受益人的协议。因此，通道拼接或闪电通道的协作关闭不会从中受益。

服务和客户端软件变更

在这个月度栏目中，我们重点介绍比特币钱包和服务的有趣更新。

  • ● Arkade 启动： Arkade 是一个 Ark 协议实现，还包括多种编程语言 SDK、钱包、BTCPayServer 插件和其他功能。

  • ● 交易池监控移动应用： Mempal Android 应用提供关于比特币网络的各种指标和警报，从自托管的交易池服务器获取数据。

  • ● 基于网络的策略和 miniscript IDE： Miniscript Studio 提供与 miniscript 和策略语言交互的界面。博客文章描述了功能，源代码可用。

  • ● Phoenix 钱包添加 taproot 通道： Phoenix 钱包添加了对 taproot 通道的支持、现有通道的迁移工作流程和多钱包功能。

  • ● Nunchuk 2.0 启动： Nunchuk 2.0 支持使用多重签名、时间锁和 miniscript 的钱包配置。它还包括降级多重签名功能。

  • ● LN Gossip 流量分析工具公布： Gossip Observer 从多个节点收集闪电网络 Gossip 消息并提供摘要指标。结果可能会为闪电网络提供类似 minisketch 的集合协调协议。Delving Bitcoin 主题包括关于该方法的讨论。

重大的代码和文档变更

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

  • ● Bitcoin Core #33745 确保通过新的挖矿进程间通信 (IPC) submitSolution() 接口（参见周报 #325）由外部 StratumV2 客户端提交的区块重新验证其见证承诺。之前，Bitcoin Core 只在原始模板构建期间检查这一点，这允许具有无效或缺失见证承诺的区块被接受为最佳链尖。

  • ● Core Lightning #8537 在首次尝试使用 MPP 支付非公开可达节点时，将 xpay 上的 maxparts 限制（参见周报 #379）设置为六。这符合基于 Phoenix 的节点对即时资助（参见周报 #323）的六个 HTLC 的接收限制，这是一种 JIT 通道。如果在该上限下路由失败，xpay 会移除限制并重试。

  • ● Core Lightning #8608 为 askrene（参见周报 #316）引入了节点级偏好，与现有的通道偏好一起。添加了新的 askrene-bias-node RPC 命令，用于偏好或不偏好指定节点的所有传出或传入通道。向偏好添加了 timestamp 字段，以便它们在一定时间后过期。

  • ● Core Lightning #8646 更新了通道拼接通道的重新连接逻辑，与 BOLTs #1160 和 BOLTs #1289 中提议的规范变更保持一致。具体来说，它增强了 channel_reestablish TLV，以便对等节点可以可靠地同步拼接状态并传达需要重传的内容。此更新对拼接通道是一个破坏性变更，所以双方必须同时升级以避免中断。参见周报 #374了解 LDK 中的类似变更。

  • ● Core Lightning #8569 在 lsp-trusts-client 模式下添加了对 JIT 通道的实验性支持，如 BLIP52 (LSPS2) 所规定，但不支持 MPP。此功能在 experimental-lsps-client 和 experimental-lsps2-service 选项后面，它代表了提供 JIT 通道完全支持的第一步。

  • ● Core Lightning #8558 添加了 listnetworkevents RPC 命令，显示对等连接、断开连接、失败和 ping 延迟的历史。它还引入了 autoclean-networkevents-age 配置选项（默认 30 天）来控制网络事件日志的保留时间。

  • ● LDK #4126 在盲化支付路径上引入了基于 ReceiveAuthKey 的身份验证验证，替换了较旧的逐跳 HMAC/nonce 方案（参见周报 #335）。这建立在 LDK #3917 的基础上，后者为盲化消息路径添加了 ReceiveAuthKey。减少逐跳数据缩小了有效载荷，并为将来的 PR 中的虚拟支付跳铺平了道路，类似于虚拟消息跳（参见周报 #370）。

  • ● LDK #4208 更新其权重估算，始终假设 72 字节 DER 编码签名，而不是在某些地方使用 72 字节，在其他地方使用 73 字节。73 字节签名是非标准的，LDK 从不产生它们。参见周报 #379了解 Eclair 中的相关变更。

  • ● LND #9432 添加了新的全局 upfront-shutdown-address 配置选项，为协作通道关闭指定默认比特币地址，除非在打开或接受特定通道时被覆盖。这建立在 BOLT2 中规定的提前关闭功能之上。参见周报 #76了解 LND 实现的之前报道。

  • ● BOLTs #1284 更新 BOLT11 以澄清，当发票中存在 n 字段时，签名必须是规范化的低 S 形式，当它不存在时，公钥恢复可以接受高 S 和低 S 签名。参见周报 #371 和 #373了解实现此行为的最新 LDK 和 Eclair 变更。

  • ● BOLTs #1044 规定了可选的可归因失败功能，它向失败消息添加归因数据，以便跳跃对它们发送的消息进行承诺。如果节点损坏失败消息，发送者可以稍后识别并惩罚该节点。有关机制和 LDK 及 Eclair 实现的更多详细信息，请参见周报 #224、#349 和 #356。