本周 Newsletter 描述了一种在比特币交易和 LN 支付中转移非比特币代币的协议，并链接到了一个关于 MuSig2 多签名协议的拟议 BIP。我们的常规栏目还包括一场 Bitcoin Core PR 审查俱乐部会议的摘要、最新的软件发布与候选发布公告，以及流行比特币基础设施软件值得注意的变更说明。

新闻

  • ● 可转移代币方案： Olaoluwa Osuntokun 发布到 Bitcoin-Dev 和 Lightning-Dev 邮件列表，提出了一组 Taro 协议的 BIP 草案，该协议允许用户在比特币区块链上记录非比特币代币的创建与转移。例如，Alice 可以发行 100 枚代币，向 Bob 转移 50 枚，而 Bob 又可以用其中 25 枚代币与 Carol 交换 10 BTC。该思路与此前在比特币上实现的方案类似，但在细节上有所不同，例如复用了 taproot 的若干设计元素以减少需要编写的新代码量，并通过使用 merkle 树来减少证明某些操作已发生时需传输的数据量。

    Taro 旨在与 LN 配合，用于可路由的链下转移。与此前在 LN 上进行跨资产转移的方案相似，仅用于路由支付的中间节点无需了解 Taro 协议或所转移资产的细节——它们只需像处理其他 LN 支付一样传递 BTC 即可。

    该想法本周在邮件列表上获得了适度的讨论。

  • ● MuSig2 提案 BIP： Jonas Nick、Tim Ruffing 和 Elliott Jin 发布了一个拟议的 BIP至 Bitcoin-Dev 邮件列表，介绍了 MuSig2 这一多签名协议，用于创建公钥与签名。多个由不同方或软件控制的私钥可以使用 MuSig2 衍生聚合公钥，而无需各方之间共享任何私密信息。随后，也可以生成聚合签名，同样无需共享私密信息。对于第三方来说，聚合公钥与聚合签名看起来就像普通公钥与 schnorr 签名，因此不会泄露参与聚合的方数或私钥数量，相比链上多签在隐私性上具有优势。

    MuSig2 在几乎所有设想的应用中都优于最初的 MuSig 提案（现称 MuSig1）。与替代方案 MuSig-DN（deterministic nonce）相比，MuSig2 更易于实现，但二者之间存在一些取舍，应用开发者在选择协议时可能希望加以权衡。

Bitcoin Core PR 审查俱乐部

在本月栏目中，我们总结最近一次 Bitcoin Core PR Review Club 会议，突出一些重要的问答。点击下面的问题可查看会议回答的摘要。

通过发送额外的 getheaders 消息防止区块索引指纹识别 是 Niklas Gögge 的一个拉取请求，旨在防止通过区块索引对节点进行指纹识别。

  • 区块索引是什么，它有什么用途？

    区块索引是在内存中的一个索引，用于查找区块头以及磁盘上区块数据的位置。它可能会保留多条分支（即包含过时区块头）的区块“树”，以便在发生重组时能够适应。 ➚

  • 我们应不应该在区块索引中保留过时区块？为什么？

    当存在多条分支时，保留它们的索引可以使节点在最多工作量链发生变化时迅速切换分支。一些与会者指出，保留非常旧的过时区块可能意义不大，因为发生重组的概率极低。然而，这些区块头占用的存储空间非常小，并且因为节点在存储之前会检查工作量证明，所以攻击者若想通过发送有效工作量证明的过时区块头来耗尽节点资源，其成本会非常高。 ➚

  • 描述一种利用节点区块索引进行指纹识别的攻击。

    在 IBD（初始区块下载）期间，节点只会请求并下载属于其在初始区块头同步过程中了解到的最多工作量链的区块。因此，其区块索引中的过时区块通常是在 IBD 之后挖出的，但这可能自然变化，也可能被拥有大量旧过时区块头的攻击者操纵。攻击者若持有包含区块头 H 和 H+1 的过时分支，可以向节点发送 H+1。若节点在其区块索引中没有 H，它会通过 getdata 消息请求 H；如果已经拥有 H，则不会请求。 ➚

  • 为何防止节点指纹识别很重要？

    节点运营者可能采取多种技术来隐藏其节点的 IP 地址，例如使用 Tor。然而，如果攻击者能够将同一节点在 IPv4 和 Tor 网络上的地址相关联，这些隐私收益就会被削弱或抵消。如果一个节点仅运行在 Tor 上，指纹识别也可能被用来将属于同一节点的多个 Tor 地址关联起来，或在节点切换到 IPv4 时识别该节点。 ➚

发布与候选发布

面向主流比特币基础设施项目的新版本与候选版本。请考虑升级至新版本，或协助测试候选版本。

值得注意的代码与文档修改

本周在 Bitcoin Core、Core Lightning、Eclair、LDK、LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、比特币改进提案（BIPs）及闪电网络规范（BOLTs）中的值得注意的变更。

  • ● Bitcoin Core #24152 通过引入包费率并以其替代单笔交易费率，允许在“子交易带未确认父交易”的包中使用 CPFP（Child-Pays-For-Parent）手续费提升。如 Newsletter #186 所述，这是提升 CPFP 和 RBF（Replace-By-Fee）手续费提升灵活性与可靠性的一系列修改的一部分。该补丁还首先验证单笔交易，以避免出现“父为子付费”或“兄弟交易互付费”等与激励不兼容的策略。

  • ● Bitcoin Core #24098 更新了 /rest/headers/ 与 /rest/blockfilterheaders/ RPC，使其可使用查询参数（例如 ?count=<count>）来替代端点参数（例如 /<count>/）。文档也已更新，鼓励优先使用查询参数。

  • ● Bitcoin Core #24147 为 miniscript 增加了后端支持。后续的 PR #24148 与 #24149 若被合并，将分别为输出脚本描述符和钱包签名逻辑加入 miniscript 支持。

  • ● Core Lightning #5165 将 C-Lightning 项目更名为 Core Lightning，简称 CLN。

  • ● Core Lightning #5086 增加了在付款中附加 option_payment_metadata 发票数据的能力，为无状态发票提供了付款方支持；接收方支持尚未在本 PR 中加入 CLN。