本周的周报总结了关于使用 P2P 协议消息对全节点进行指纹识别的研究，并就可能在 BIP380 描述符规范中移除对 BIP32 路径中 H 的支持寻求反馈。此外还包括我们的常规部分：总结了 Bitcoin Stack Exchange 上的热门问答、新版本和候选版本的公告，以及对热门比特币基础设施软件的重大变更介绍。

新闻

• ● 使用 addr 消息对节点进行指纹识别： Daniela Brozzoni 在 Delving Bitcoin 上发布了她与开发者 Naiyoma 进行的研究，该研究关于使用节点发送的 addr 消息在多个网络上识别同一个节点。节点向其对等节点发送 P2P 协议 addr（地址）消息来广告其他潜在节点，允许对等节点使用去中心化的 gossip 系统找到彼此。然而，Brozzoni 和 Naiyoma 能够使用其特定地址消息的详细信息对单个节点进行指纹识别，使他们能够识别在多个网络（如 IPv4 和 Tor）上运行的同一个节点。

  研究人员建议了两种可能的缓解措施：从地址消息中移除时间戳，或者如果保留时间戳，则稍微随机化它们以使其对特定节点的特异性降低。

• ● 是否有软件在描述符中使用 H？ Ava Chow 在 Bitcoin-Dev 邮件列表上发布询问是否有任何软件生成使用大写 H 来表示强化 BIP32 密钥派生步骤的描述符。如果没有，输出脚本描述符的 BIP380 规范可能会被修改为只允许使用小写 h 和 ' 来表示强化。Chow 指出，虽然 BIP32 允许大写 H，但 BIP380 规范之前包含了一个禁止使用大写 H 的测试，并且 Bitcoin Core 目前不接受大写 H。

Bitcoin Stack Exchange 的精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找问题答案的首选之地之一，也是我们有闲暇时会给好奇和困惑的用户帮忙的地方。在这个月度栏目中，我们会列举自上次出刊以来出现的一些高票的问题和答案。

• ● 有什么方法可以阻止 Bitcoin Knots 节点作为我的对等节点吗？ Vojtěch Strnad 提供了一种基于用户代理字符串使用两个 Bitcoin Core RPC 阻止对等节点的方法，但不鼓励这种方法，并指向了一个相关的 Bitcoin Core GitHub issue，其中也有类似的不鼓励意见。

• ● OP_CAT 对整数如何操作？ Pieter Wuille 解释说 Bitcoin Script 堆栈元素不包含数据类型信息，不同的操作码以不同的方式解释堆栈元素的字节。

• ● 使用致密区块中继的异步区块中继（BIP152） 用户 bca-0353f40e 概述了 Bitcoin Core 对致密区块的处理，并估计了缺失交易对区块传播的影响。

• ● 为什么自私挖矿中攻击者的收入与其算力不成比例？ Antoine Poinsot 跟进了这个和另一个较早的自私挖矿问题，指出“难度调整不考虑陈旧区块，这意味着降低竞争矿工的有效算力会增加矿工的利润（在足够长的时间尺度上），就像增加自己的算力一样”，（参见周报 #358）。

新版本和候选版本

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

• ● Bitcoin Core 28.2 是主流全节点实现的前一个发布系列的维护版本。它包含多个错误修复。

重大的代码和文档变更

本周的重大变更有：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 #31981 向进程间通信（IPC）Mining 接口（参见周报 #310）添加了一个 checkBlock 方法，该方法执行与 proposal 模式下的 getblocktemplate RPC 相同的有效性检查。这使得使用 Stratum v2 的矿池能够通过更快的 IPC 接口验证矿工提供的区块模板，而不是通过 RPC 序列化多达 4 MB 的 JSON。可以在选项中禁用工作量证明和默克尔根检查。

• ● Eclair #3109 将其可归因故障支持（参见周报 #356）扩展到蹦床支付。蹦床节点现在解密并存储为其准备的归因载荷部分，并为下一个蹦床跳跃准备剩余的数据块。此 PR 不实现蹦床节点的归因数据中继，这预计在后续 PR 中实现。

• ● LND #9950 向 DescribeGraph、GetNodeInfo 和 GetChanInfo RPC 以及它们对应的 lncli 命令添加了一个新的 include_auth_proof 标志。包含此标志会返回通道公告签名，允许第三方软件验证通道详细信息。

• ● LDK #3868 将可归因故障（参见周报 #349）载荷的 HTLC 持有时间精度从 1 毫秒单位降低到 100 毫秒单位，以减轻时序指纹泄露。这使 LDK 与 BOLTs #1044 草案的最新更新保持一致。

• ● LDK #3873 将在注资输出被花费后忘记短通道标识符（SCID）的延迟从 12 个区块增加到 144 个区块，以允许通道拼接更新的传播。这是 BOLTs #1270 中引入的 72 个区块延迟的两倍，Eclair 已实现该延迟（参见周报 #359）。此 PR 还实现了对 splice_locked 消息交换过程的额外更改。

• ● Libsecp256k1 #1678 添加了一个 secp256k1_objs CMake 接口库，该库公开了库的所有目标文件，以允许父项目（如 Bitcoin Core 计划的 libbitcoinkernel）将这些目标直接链接到它们自己的静态库中。这解决了 CMake 缺乏将静态库链接到另一个静态库的原生机制的问题，并使下游用户免于提供自己的 libsecp256k1 二进制文件。

• ● BIPs #1803 通过允许所有常见的强化路径标记来澄清 BIP380 的描述符语法，而 #1871、#1867 和 #1866 通过收紧密钥路径规则、允许重复参与者密钥和明确限制多路径子派生来完善 BIP390 的 MuSig2 描述符。