本周的 Newsletter 描述了用于 JoinMarket 风格去中心化 CoinJoin 的 Fidelity Bonds，提到了一个用于 BIP322 signmessage 支持的 PR（包括对 bech32 地址的签名能力），并总结了关于布隆过滤器的讨论。还包括我们常规的关于 bech32 支持、Bitcoin Stack Exchange 精选问答以及值得注意的比特币基础设施项目的变更内容。

行动项

  • ● 帮助测试 Bitcoin Core 0.18.1 候选版本：即将发布的这个维护版本修复了影响某些 RPC 命令的多个 bug，并在某些情况下导致 CPU 使用率不必要地高。建议生产环境用户测试当前的候选版本，以确保其按预期运行。

新闻

  • ● 用于改善 Sybil 抵抗性的 Fidelity Bonds：JoinMarket 开发者 Chris Belcher 在 Bitcoin-Dev 邮件列表中发布了关于解决去中心化 CoinJoin 实现中已知问题的可能解决方案。JoinMarket 的用户可以作为 makers（广告参与 CoinJoin 的意愿者）或 takers（选择 makers 进行混币的人）进行操作。一个单一的 Sybil 攻击者可能冒充足够多的不同 makers，以至于在几乎每次 CoinJoin 中都能选择到一个或多个他们的马甲，从而能够消除或显著减少 CoinJoin 的隐私收益。

    Belcher 提出，makers 可以通过销毁（“焚烧”）比特币或长时间锁定比特币来创建持久的加密身份。这些牺牲将伴随着一个公钥，makers 可以使用它来签署其在 JoinMarket 中的临时身份。然后，takers 会随机选择符合条件的 makers 进行 CoinJoin，选择权重根据他们牺牲的大小（由公式决定）来计算。

    好处是，这将要求攻击者牺牲大量的比特币或出售比特币的能力，从而使 Sybil 攻击变得更加昂贵。不利的一面是，诚实的 makers 可能会为 CoinJoin 收取更多费用，以补偿他们的牺牲，从而增加 JoinMarket CoinJoin 的成本。

  • ● 为 BIP322 通用签名消息格式开启的 PR：Kalle Alm 向 Bitcoin Core 提交了一个PR，实现了 BIP322，更新了 signmessage、signmessagewithprivkey 和 verifymessage RPC，以支持对 P2WPKH 和 P2SH-P2WPKH 地址的签名，除了传统的 P2PKH 地址之外。该 PR 目前正在寻求反馈和概念性审查。尽管此 PR 仅提供了 BIP322 支持的基本实现，未来的扩展可以让 Bitcoin Core 对任何可消费的脚本进行消息签名和验证，并且这种支持可以轻松升级以适应未来脚本语言的变化，如 taproot。希望其他钱包也能考虑实现 BIP322，以提供灵活的前向兼容的消息签名支持。请参阅 Optech 之前的 bech32 部分，我们曾遗憾地提到缺乏 BIP322 的实现。

    基于对该 PR 的早期反馈，BIP322 还进行了更新，以便使用传统 P2PKH 密钥签名和验证消息时使用旧的 signmessage 格式。这使得 BIP322 工具能够完全向后兼容现有的、广泛实施的 signmessage 标准（该标准仅支持 P2PKH）。

  • ● 布隆过滤器讨论：在上周 Newsletter 的 值得注意的变更 部分中，我们提到了一个已合并的 PR，该 PR 禁用了 Bitcoin Core 默认配置中的布隆过滤器。PR 的作者在 Bitcoin-Dev 邮件列表中宣布了这一未发布的更改，几个人对此发表了问题或担忧。讨论的一些要点包括：

    • ● 无需紧急行动：截至撰写本文时，接受入站连接的节点（监听节点）中有超过 20% 运行的是一年以上的 Bitcoin Core 版本 根据 BitNodes 数据。至少 5% 运行的是两年以上的版本。推断到未来，这意味着到 2022 年初，仍将有超过 500 个监听节点提供布隆过滤器支持。因此，即使不采取进一步行动，钱包开发者可能仍有足够的时间来调整他们的程序。

    • ● 间谍可能会运行自己的节点：除了未升级的节点之外，区块链分析公司可能会继续运行自己的节点，以在未来提供布隆过滤器支持，从而收集钱包的统计数据，这些数据的过滤器泄露信息关于它们包含的地址。

    • ● DNS seeds 只能返回信号 BIP111 的节点：大多数 P2P 轻钱包会查询一个或多个比特币 DNS seeds 以获取要使用的节点列表。一些 seeds 允许根据节点配置的服务比特来筛选返回的节点1，其中支持布隆过滤器的服务位由 BIP111 指定。

    • ● BIP157 将使用比 BIP37 更多的带宽：有人建议，一些使用 BIP37布隆过滤器的用户将无法切换到 BIP157 致密区块过滤器，因为后者的带宽使用更高。Optech 在 Newsletter #43 中简要调查了过滤器大小，发现过滤器本身每月使用不到 100 MB。客户端还需要下载匹配的区块，这将根据其活动而有所不同（对于典型用户来说，大约每个发送或接收的交易对应一个区块；大多数区块小于 2 MB）。目前尚不清楚有多少用户会因必须下载这些数据量而受到显著影响。

    • ● 感兴趣的方可以运行自己的节点：对 Bitcoin Core 的更改只是默认禁用布隆过滤器服务。它并没有移除这个功能。依赖布隆过滤器支持的钱包的作者可以轻松地操作自己的节点，他们也可以尝试说服其他不担心 DoS 漏洞的节点操作员将配置选项设置为 true，例如 peerbloomfilters=1。

Bech32 发送支持

在系列中的第 20 周，讨论如何让你支付的人获得 segwit 的所有好处。

在过去的一年中（大约 50,000 个区块），以百分比计算，原生 segwit 输出（即支付到 bech32 地址的交易数量）略有下降。一个明显的解释是，人们尝试了 bech32 地址，但不喜欢，随后又回到使用传统地址或 P2SH 包裹的 segwit 地址。如果情况确实如此，我们是否应该放弃 bech32 地址？

支付给原生 segwit（bech32）输出的所有交易的百分比

注意：本节中的所有图表都使用简单移动平均值计算，范围为 10,000 个区块。

或许我们应该首先调查是否存在其他解释。百分比是合成结果——通过结合多个其他来源的信息得出——所以我们首先要看的是原始数据。下图显示了过去两年中支付给各种类型脚本的输出总数：

支付给 P2PKH、P2SH、bech32 和 nulldata 的所有交易的总数

与百分比数据相反，我们看到 P2WPKH 输出的数量在缓慢（但稳定）增加。我们还看到其他输出的数量也在增加。如果将总数堆叠在一起，这可能会变得更加清晰：

支付给 P2PKH、P2SH、bech32 和 nulldata 的所有交易总数的堆叠图

现在我们可以看到，今天的平均输出数量略高于 2017 年底和 2018 年初比特币活动高峰时的数量。这是有道理的——使用 segwit 的交易越多，留给其他交易的区块空间就越多。然而，尽管整体增加，但支付输出（P2PKH、P2SH 和原生 segwit）的数量略有减少。剩余的输出显示出 OP_RETURN（nulldata）脚本数量的显著增加。

输出总数和 nulldata 输出数量的增长解释了为什么尽管绝对数量在增加，但 bech32 输出的百分比却在下降。这意味着我们不应该放弃 bech32。事实上，近期输出总数的激增（以及其他可在其他地方获取的数据）可能是即将到来的费率上涨的信号，这将鼓励更多用户和组织通过切换到 bech32 来降低成本。

Bitcoin Stack Exchange 精选问答

Bitcoin Stack Exchange 是 Optech 贡献者寻找问题答案的首选之一——或者在我们有空闲时间时帮助好奇或困惑的用户。在这个每月特刊中，我们精选自上次更新以来的一些最高票问题和答案。

值得注意的代码和文档变更

本周 Bitcoin Core、LND、C-Lightning、Eclair、libsecp256k1、比特币改进提案（BIPs）和闪电网络规范中的值得注意的变更。

  • ● BIPs #800 更新了 BIP174，指出钱包只能使用在部分签名比特币交易（PSBT）中请求的签名哈希（sighash）类型进行签名，前提是钱包认为该 sighash 类型提供了可接受的安全性。处理常见交易类型的大多数钱包应该拒绝 SIGHASH_ALL 之外的任何东西。

  • ● BIPs #766 为在Newsletter #37中描述的 addr v2 提议分配了 BIP155。此提案将允许节点相互分享它们的 Tor 隐藏服务（onion）版本 3 地址，并提供与其他网络地址协议的兼容性。

  • ● BIPs #643 添加了 BIP301，讨论了盲合并挖矿，此前曾在 2017 年底的 Bitcoin-Dev 邮件列表中讨论过。盲合并挖矿旨在与称为“Drivechains”的去中心化侧链一起使用。与其他去中心化侧链提议类似，Drivechains 具有 SPV 安全性，这意味着拥有足够算力的矿工能够从侧链用户那里窃取资金。

  • ● C-Lightning #2842 当从通道对等节点收到“同步错误”时触发重连尝试，而不是导致通道失败。这是有意偏离闪电网络规范的决定，因为 LND 节点似乎经常生成此错误，而 C-Lightning 维护者担心，如果 C-Lightning 按照规定的速率正确地导致通道失败，我们有可能导致网络分裂。

脚注

  1. 例如，我们在此查询一个具有完整链历史记录（NODE_NETWORK）和布隆过滤器支持（NODE_BLOOM）的服务位启用节点的 seed：

    $ python3
>>> NODE_NETWORK = 1 << 0  ## 原始比特币 0.1 协议
>>> NODE_BLOOM = 1 << 2    ## BIP111
>>> hex(NODE_NETWORK | NODE_BLOOM)
'0x5'

$ dig x5.seed.bitcoin.sipa.be
[...]

;; ANSWER SECTION:
x5.seed.bitcoin.sipa.be. 3118	IN	A	84.77.52.0
x5.seed.bitcoin.sipa.be. 3118	IN	A	165.227.110.22
x5.seed.bitcoin.sipa.be. 3118	IN	A	52.163.63.49
[...]

    ↩