这周的 Newsletter 宣布 Bitcoin Core 新版本的发布，提供了关于比特币和闪电网络（LN）开发者邮件列表的一些更新，并描述了当前 schnorr/taproot 评审的最新进展。此外，还有我们常规的部分，包括 Bitcoin Stack Exchange 精选问答和对流行比特币基础设施项目的值得注意的更改。

行动项

  • ● 升级到 Bitcoin Core 0.19.0.1： 鼓励用户升级到最新的 release，该版本包含新特性和多个漏洞修复。这是 0.19 系列的第一个发布版本，之前发现并修复了一个影响 0.19.0 标记版本的 bug。

新闻

  • ● Bitcoin Core 0.19 发布： 新版包含来自 100 多位贡献者的超过 1000 次提交，最新的 Bitcoin Core release 提供了多个用户可见的特性、众多的漏洞修复以及多个对内部系统（如 P2P 网络处理）的改进。一些可能对 Newsletter 读者特别感兴趣的更改包括：

    • ● CPFP carve-out： 这一新内存池政策帮助双方合同协议（如当前的闪电网络）确保双方能够使用 Child-Pays-For-Parent (CPFP) 的费用增加功能（详见 Newsletter #63）。闪电网络开发者已经在讨论如何利用这一特性简化承诺交易的费用管理（详见 Newsletter #70 和 Newsletter #71）。

    • ● BIP158 区块过滤器（仅限 RPC）： 如果用户希望 Bitcoin Core 生成致密区块过滤器，可以设置新的配置选项 blockfilterindex，按照 BIP158 的要求生成每个区块的过滤器。然后可以使用新的 RPC getblockfilter 检索每个区块的过滤器。过滤器可以提供给兼容的轻量客户端，以帮助其确定某个区块是否可能包含与其密钥相关的交易（有关更多信息，详见 Newsletter #43）。当前正在开放的 PR#16442 旨在为相应的 BIP157 协议添加支持，以便在 P2P 网络上与客户端共享这些过滤器。

    • ● 弃用或移除的功能： 默认情况下，已禁用对 BIP70 支付协议、BIP37 P2P 协议布隆过滤器和 BIP61 P2P 协议拒绝消息的支持，从而消除了各种问题的源头（分别详见 Newsletter #19、Newsletter #57 和 Newsletter #37）。支付协议和拒绝消息计划在下一个主要的 Bitcoin Core 版本中彻底移除，预计约在六个月后。

    • ● 可定制的白名单对等节点权限： 在指定哪些对等节点或接口应被列入白名单时，用户现在可以指定这些白名单对等节点可以访问的特殊功能。之前，白名单对等节点不会被禁止，并且接收转发交易的速度更快。这些默认设置没有改变，但现在可以按每个对等节点的基础切换这些设置，或允许指定的白名单对等节点请求 BIP37 布隆过滤器，尽管默认情况下对非白名单对等节点禁用。有关详细信息，参见 Newsletter #60。

    • ● 图形用户界面改进： 图形用户现在可以通过 GUI 的 文件 菜单为多钱包模式创建新钱包（详见 Newsletter #63）。GUI 现在默认为用户提供 bech32 比特币地址，但用户可以轻松请求向后兼容的 P2SH-P2WPKH 地址，只需在生成地址的按钮旁边勾选一个复选框即可（详见 Newsletter #42）。

    • ● 可选的隐私保护地址管理： 可以通过新的 avoid_reuse 钱包标志防止钱包支出先前使用过的地址收到的比特币，该标志可以通过新的 setwalletflag RPC 切换（详见 Newsletter #52）。这可以防止某些基于区块链分析的隐私泄露，例如 dust flooding。

    有关值得注意的更改的完整列表、这些更改的 PR 链接以及对节点操作员有用的其他信息，请参见 Bitcoin Core 项目的 release notes。

  • ● 新的 LND 邮件列表和现有邮件列表的新主机： 宣布了一个由 Google Groups 托管的新邮件列表，面向 LND 应用开发者，并由 Olaoluwa Osuntokun 发布了初始帖子，描述了 LND 下一个版本的短期目标。此外，现有的 Bitcoin-Dev 和 Lightning-Dev 邮件列表的托管最近已转移到俄勒冈州立大学的 Open Source Lab (OSL)，这是一个备受尊敬的组织，为多种开源项目提供托管。Optech 对 Warren Togami、Bryan Bishop 以及其他所有参与维护比特币众多开放通信渠道的人表示感谢，没有他们，这份 Newsletter 将无法存在。

  • ● Schnorr/Taproot 更新： taproot review group 的参与者继续评审对比特币的提议软分叉更改，许多有趣的问题在 Freenode 网络的 logged ##taproot-bip-review IRC 聊天室中被提出和回答。此外，一些参与者正在编写 BIPs 部分的自己的实现，包括 libbitcoin 和 bcoin 完整验证节点。

    本周还发布了两篇与多方 schnorr 签名安全性相关的博文。Blockstream 工程师 Jonas Nick 描述了旨在允许 bip-schnorr 用户将多个公钥聚合为单个公钥的 MuSig 多方签名方案。他们可以随后使用在自己之间协作生成的单个签名为该公钥签名。Nick 描述了 MuSig 签名协议的三个步骤——非对称承诺的交换、非对称数的交换和部分签名的交换（其中非对称数和部分签名随后被聚合以生成最终签名）。为了在速度至关重要时节省时间（例如在创建 LN 通道承诺交易时），一些人可能希望在知道想要承诺的交易之前先交换非对称承诺和非对称数——但由于 Wagner 算法，这样做是不安全的，正如 Nick 简要解释的那样。每个参与者知道要签名的交易之前，唯一可以安全共享的信息是非对称承诺。（博客中没有提到，但在 IRC 中讨论的是，Pieter Wuille 和其他人一直在研究基于零知识证明（ZKP）的构造，这可能允许减少交互。）博客的结尾建议感兴趣的读者查看 libsecp256k1-zkp 中的 MuSig 实现，以帮助开发人员安全使用该协议。

    受到 Jonas Nick 在柏林闪电网络会议上对这一主题的演讲的影响，Adam Gibson 撰写了另一篇博客帖子，更详细地描述了 Wagner 算法，结合了数学、直观分析和比特币爱好者可能感兴趣的主题信息（例如 Wagner 的论文中提到 Adam Back 和 Wei Dai 的趣闻，早于中本聪同样的引用，尽管是出于不同的工作）。任何有兴趣开发自己加密协议的人都建议阅读这两篇帖子，因为它们互为补充，而不重复相关主题。

Bitcoin Stack Exchange 精选问答

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

  • ● schnorr 公钥的长度会与 taproot 公钥不同吗，比如 P2WPKH 和 P2WSH？ Murch 解释说，与具有不同 P2WPKH 和 P2WSH 输出类型和长度的 segwit v0 不同，所有 segwit v1 Pay-to-Taproot (P2TR) 输出的长度始终相同。

  • ● MuSig 签名交互性 Justinmoon 询问为什么 MuSig 签名总是需要交互以及关于安全的离线交互签名。Nickler 解释了 MuSig 签名中每一轮的过程以及在签名时需要避免的一些陷阱。

  • ● bech32 的长度扩展突变弱点是如何工作的？ Jnewbery 询问为什么在地址最后一个 p 字符之前立即添加或删除 q 字符有时会生成一个有效的新 bech32 地址。Pieter Wuille 提供了一些代数细节，说明这一问题比任何随机长度变化错误未被发现的概率（大约 1/十亿）更容易发生。MCCCS 提供了一个第二种解释，使用了一些来自 Bitcoin Core 的适用代码。

  • ● 比特币政策语言与 Miniscript 之间的区别是什么？ Pieter Wuille、James C. 和 sanket1729 解释了比特币脚本、政策语言（用于人类设计支出条件的工具）和 miniscript（用于通信和分析的比特币脚本的更结构化表示）之间的关系。

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

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

  • ● Bitcoin Core #17265 和 #17515 完成了对 OpenSSL 依赖的移除，自比特币 0.1 版本以来一直使用，但造成了共识漏洞、远程内存泄漏（可能的私钥泄漏）、其他错误和性能差。

  • ● Bitcoin Core #16944 更新 GUI 以生成 BIP174 部分签名比特币交易 (PSBT)，如果用户尝试在禁用私钥的观察钱包中创建交易，系统会自动将其复制到剪贴板。PSBT 可以复制到其他应用程序进行签名（例如 HWI）。GUI 目前尚未提供特定对话框以将签名后的 PSBT 复制回来以进行广播。

  • ● Bitcoin Core #17290 更改用户请求某些输入或要求从支付金额中选择费用时使用的币选择算法。现在使用 Bitcoin Core 的正常默认算法分支和边界（BnB）。BnB 被设计为通过优化创建无零钱交易来最小化费用并最大化隐私。

  • ● C-Lightning #3264 包含了多个针对 LND #3728 的缓解措施，这是在 gossip 查询实现中的一个错误。此更改还添加了两个新的命令行参数，方便测试和调试，分别为 --hex 和 --features。

  • ● C-Lightning #3274 导致 lightningd 如果检测到 bitcoind 的区块高度低于上次运行时的高度，则拒绝启动。如果在 lightningd 运行时检测到较低高度，它将等待直到看到更高的高度。区块高度可能在区块链重组、区块链重新索引期间降低，或用户运行某些开发测试命令时降低。对于 lightningd 来说，等待这些情况由 bitcoind 解决比尝试绕过问题要更容易和安全。然而，如果 LN 用户真的想使用被截断的链，他们可以使用 --rescan 参数重新处理区块链。

  • ● Eclair #1221 添加了一个 networkstats API，返回本地节点观察到的闪电网络的各种信息，包括已知通道的数量、已知 LN 节点的数量、LN 节点的容量（按百分位数分组）以及节点收取的费用（也按百分位数分组）。

  • ● LND #3739 使用户能够指定在支付送达接收者之前，哪个节点应成为最后一跳。结合其他仍在待处理的工作，如 LND #3736，这将使用户能够使用内置的 LND 功能对其通道进行重新平衡（而不是目前需要外部工具）。

  • ● LND #3729 使生成具有毫微比特（millisatoshi）精度的发票成为可能。以前，LND 不会生成具有亚比特（sub-satoshi）精度的发票。

  • ● LND #3499 扩展了几个 RPC，例如 listpayments 和 trackpayment，以提供有关多路径支付的信息，这些支付可以分成多个部分通过不同路径发送。虽然 LND 目前尚未完全支持这些，但此合并的 PR 使后续添加支持变得更容易。此外，之前发送的仅包含一部分的支付被转换为用于多路径支付的相同结构，但它们仅显示为一部分。