本周的 Newsletter 请求对 LND 和 C-Lightning 的候选版本（RCs）进行测试，描述了使用 ECDH 实现未协调的闪电网络（LN）支付，总结了一个提案，该提案建议在 LN 路由回复中添加延迟信息，并总结了最近在阿姆斯特丹举办的 “Breaking Bitcoin” 会议上一些有趣的演讲内容。此外，还包括我们常规的 bech32 发送支持和流行比特币基础设施项目中的值得注意的变化。

行动项

  • ● 帮助测试 C-Lightning 和 LND 的候选版本： C-Lightning 和 LND 都在测试下一个版本的候选版本（RC）。鼓励这两个程序的经验用户帮助测试 RC，以便在最终发布前识别并修复任何剩余的错误。

新闻

  • ● 使用 ECDH 实现未协调的 LN 支付： Stephan Snigirev 向 LN 开发邮件列表发送了两个想法，并在单个帖子中进行了描述。第一个想法是重用现有的协议部分来实现自发支付，即 Alice 向 Bob 发送支付，而无需 Bob 提供发票。正如 Newsletter #30 所述，目前 LND 提出的自发支付方案是让 Alice 选择一个预映像，将其加密到 Bob 的密钥中，并将其放入 LN 路由数据包中一个未使用的部分，然后 Alice 支付该预映像的哈希。当 Bob 收到加密的预映像后，他解密并释放它以获取支付。

    Snigirev 的想法消除了路由加密预映像的需求。他指出，从 Alice 到 Bob 的支付路由已经要求他们拥有一个共同的共享秘密（通过椭圆曲线迪菲-赫尔曼（ECDH）派生）。这个秘密可以通过哈希生成一个唯一的预映像，该预映像对他们双方都是已知的，然后再对该预映像进行哈希以生成支付哈希。使用此系统时，每当 Bob 收到一个他没有创建发票的哈希支付时，他只需生成该会话共享秘密的双重哈希，看看它是否匹配。如果匹配，他就生成单个哈希并获取支付。C-Lightning 开发者 Christian Decker 已编写了一个概念验证补丁和插件，用于 C-Lightning 实现这一功能。

    Snigirev 的第二个想法允许离线设备（如自动售货机）生成一个独特的 LN 发票，在线用户可以向另一个在线节点支付该发票，该节点可以生成预映像并代表离线设备获取支付。这样，支付者会收到作为支付证明的预映像，然后可以将此证明展示给离线设备以获取承诺的商品或服务，例如从自动售货机获取食品。这同样使用了通过 ECDH 派生的共享秘密——但在这种情况下，秘密是在生成发票的离线设备和最终接收支付的在线节点之间共享的。有关协议详情，请参见 Snigirev 的帖子。

  • ● 验证 LN 延迟信息的消息： 当 LN 中的支付失败时，尝试支付的节点通常可以从导致支付失败的两个节点之一收到认证消息。这允许支付节点将这两个节点之间的通道标记为不可靠，并在未来支付中选择其他通道。但 LND 开发者 Joost Jager 在 LN 开发邮件列表中指出，“非理想支付尝试也可能是成功的支付，只是接收成功消息的时间过长。”他提议每个节点在将消息传递回支付节点时，向消息中添加两个时间戳，一个是节点提议路由支付的时间戳，另一个是节点得知支付失败或成功的时间戳。这将使支付节点能够确定支付路由过程中延迟发生的位置，并在未来避免这些通道。

    为防止路径上的某些节点对其他节点撒谎，他建议用消息认证码保护错误消息和时间戳。这也可以防止中间节点损坏来自端点节点的加密错误消息。

    Jager 的提案还讨论了如何在当前路由协议中实现这种类型的系统，以及如何解决与路由隐私相关的担忧。到目前为止，这一提案在邮件列表中已引起了适度的积极讨论。

Breaking Bitcoin

Breaking Bitcoin 是一个比特币技术会议，上周末在阿姆斯特丹举行。比特币协议开发者和应用工程师都参加了会议。周六和周日的视频已发布，比特币开发者 Bryan Bishop (kanzure) 也提供了几份演讲记录。

以下演讲可能会特别引起 Bitcoin Optech Newsletter 读者的兴趣：

  • ● Breaking Bitcoin 隐私 - Chris Belcher，Joinmarket 的 coinjoin 实现的创建者，概述了比特币中的隐私问题。Belcher 之前写过一篇关于隐私的文献综述，在这次非常易懂的演讲中，他提到了综述中的许多主题。他首先解释了为什么隐私在比特币中很重要，描述了链分析公司用于链接比特币地址和交易的一些常用启发法，并展示了 coinjoins 和 payjoins 如何被用来打破这些启发法并阻止链分析。他最后谈到了第二层技术（如闪电网络）如何通过从区块链中移除泄露隐私的数据来改善隐私。（演讲记录）。

  • ● 比特币构建系统安全性 - Chaincode Labs 工程师 Carl Dong 进行了预录的比特币 Core 构建安全性演讲，并通过视频链接回答了观众问题。Dong 的演讲回答了一个问题：“如果我从 bitcoincore.org 下载比特币 Core 可执行文件，我如何知道我运行的是什么代码？”比特币 Core 项目目前使用可复现的 gitian 构建来确保构建的二进制文件与源代码相对应，但 Dong 解释说，可复现性是不够的——如果可复现构建工具链使用了预编译的二进制文件，那么这些工具链二进制文件可能会被破坏，并被用来在编译的二进制文件中无察觉地插入恶意代码。Dong 接着描述了_可复现的_和_可引导的_构建，其中工具链中使用的预编译二进制文件数量被减少到最低限度，并且他还介绍了将 guix（发音为‘geeks’）构建集成到比特币 Core 中的项目进展，以尽量减少对构建工具链的信任。（演讲记录）。

  • ● bip-taproot 上的安全协议 - Blockstream 工程师 Jonas Nick 更新了他和同事们使用 schnorr 签名和 taproot 结构构建安全协议的一些工作进展。他首先解释了提议的 bip-taproot 如何工作（更多背景信息），然后解释了使用 schnorr/taproot 构建协议时的一些实际考虑：不能通过 nonce 偏差泄露私钥的外部签名器、使用 Musig 进行的密钥聚合和门限签名，以及盲 schnorr 签名。随着 schnorr/taproot 提案的发展并（可能）接近激活，希望利用该提案提供的新功能的公司需要考虑构建安全产品和协议的这些实际方面。（演讲记录）。

  • ● 从硬件钱包中提取种子 - Ledger CSO Charles Guillemet 发表了一场关于市面上几款硬件钱包安全问题的令人震惊的演讲。他讨论了他和他的团队发现的先前披露的漏洞，以及为了保护用户他没有透露方法的新漏洞。描述的攻击使用了物理访问、侧信道和利用不安全的密码实现的混合方法。这是一场令人着迷的演讲，适合任何使用或使用硬件钱包来保护其比特币的人士。（演讲记录）。

  • ● 门限钱包中的密码学漏洞 - schnorr 签名的最受期待的方面之一是实现密钥聚合和门限签名方案的能力。使用目前在比特币中使用的 ECDSA 签名算法也可以实现类似的方案（尽管实现起来复杂得多）。ZenGo 联合创始人 Omer Shlomovits 介绍了其中一些 ECDSA 密钥聚合和门限签名方案，并展示了由于在优化算法时的错误假设，这些方案的许多实现包含了漏洞。（无演讲记录可用）。

Bech32 发送支持

关于让你的支付对象访问 segwit 所有好处的系列文章的第 14 周，共 24 周。

有一类多重签名用户不仅通过使用 bech32 地址来节省费用，还因提高了对一种称为哈希碰撞的潜在攻击的安全性而受益。这类用户包括许多交易所和其他企业用户。

为了提供一些背景信息，目前比特币上的所有常见单签名地址都是通过将公钥转换为 160 位的 RIPEMD160 哈希摘要而生成的。理论上，攻击者可以生成第二个他们控制的公钥，对其进行哈希并生成相同的地址。然而，如果我们假设哈希函数产生的输出是完全不可预测的，那么使用像 RIPEMD160 这样的 160 位哈希函数时，每次攻击者尝试生成哈希碰撞的成功概率为 1/2160。

作为比较，当前比特币矿工大约每 5 小时执行 280 次哈希操作。虽然矿工执行的 SHA256d 哈希操作与此 RIPEMD160 碰撞攻击使用的哈希操作不同，因此他们的设备无法被重新利用来进行这种攻击，但我们可以用此作为一个参考，以了解当前真实世界系统可以执行的暴力破解操作数量（虽然代价昂贵）。按此速度，执行 2159 次操作以获得 50% 成功率的攻击将需要大约 2500 万倍于宇宙至今的估计年龄的时间。

然而，当使用多重签名地址时，攻击者可能是参与生成地址的一方，因此可能有能力操纵最终选择的地址。例如，Bob 将他的公钥发送给 Mallory，期望 Mallory 也将她的公钥返回给他。然后他们各自将公钥放入一个多重签名脚本模板中，哈希成一个地址，并有人将资金存入该地址。

然而，Mallory 采用了脚本模板和 Bob 的公钥，在没有告知 Bob 的情况下插入了她的一个公钥，并将其哈希成一个地址。这样，Mallory 可以在她承诺使用该公钥之前查看 Bob 将接受的地址。然后，Mallory 可以将该地址与她的数据库中仅支付给她的脚本生成的地址进行比较。如果两个地址匹配（碰撞），她就将公钥返回给 Bob，等待资金存入该地址，然后使用她数据库中的脚本来窃取资金。如果没有匹配，Mallory 可以一次又一次地尝试不同的公钥，直到她成功（假设她有无限的时间和资源）。

虽然这似乎与之前描述的具有每次尝试 1/2160 成功概率的暴力攻击类似，但我们必须考虑 Mallory 数据库的大小。如果我们假设该数据库有 100 个地址，那么她每次尝试不同的公钥时的成功概率为 100/2160，因为只要它与 Mallory 数据库中的任何一个地址匹配就可以成功。

这种攻击类型称为碰撞攻击。碰撞攻击有几种在 CPU/内存方面进行权衡的算法，但安全研究人员遵循的通用规则是，针对完美哈希函数的碰撞攻击将其安全性降低到其组合数的平方根，即将其位数减半。这意味着我们可以大致认为 RIPEMD160 的安全性降低到 80 位——这与我们之前提到的当前技术下比特币矿工每 5 小时执行的操作次数相同。再一次，比特币挖矿设备无法用于此攻击，并且攻击者设计和构建足够的定制设备以在五小时内找到碰撞可能需要花费数十亿美元——但这是一个理论上可能的攻击，应该引起那些在 P2SH 中存储大量价值的人的关注，尤其是在定制硬件变得更快和更便宜的时候。此外，RIPEMD160 函数中可能存在的弱点也可能导致有更简单和更便宜的碰撞攻击变体。

可以设计多重签名设置协议，使其没有这个问题，从而保持 160 位的碰撞抵抗性。然而，segwit 的开发者认为，对于 segwit 的 P2SH 类似物——P2WSH——使用稍长的哈希函数更为合适，这样用户就不需要担心这些密码学细节。因此，segwit P2WSH 使用了比特币中其他地方使用的相同的 SHA256d 函数，该函数为单方情况下提供 256 位安全性，为多方情况下提供 128 位的最差安全性。为了继续我们的粗略比较，如果我们认为 80 位相当于五小时的比特币挖矿，那么 128 位相当于 1600 亿年的挖矿。

在我们总结这一部分之前，我们想确保几件事情是清楚的：

  1. 我们认为目前没有人能够执行所描述的攻击（但我们不能排除这种风险）。

  2. 该攻击只能在创建地址时使用（尽管实际盗窃可能会在很长时间后发生）。

  3. 该攻击仅适用于多方多重签名地址。如果你是使用仅自己信任设备的 P2SH 多重签名单方用户，或者你使用的是 P2SH-P2WPKH（单签名地址），则你不会受到此攻击的威胁。

  4. 该攻击适用于 P2SH 包装的 segwit P2WSH 地址以及常规 P2SH 地址。要消除风险，你必须使用原生 segwit（bech32）地址或安全的密钥交换协议。

总结来说，希望获得最高安全性的多方多重签名用户应该迁移到 bech32 P2WSH 地址，以利用其额外的碰撞抵抗性。随着用户进行这种迁移，各服务确保他们实现 bech32 发送支持以便能够向这些注重安全的用户发送支付将变得更加重要。

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

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

  • ● Bitcoin Core #15024 允许 importmulti RPC 使用输出脚本描述符派生特定的私钥，然后导入所得的密钥。

  • ● Bitcoin Core #15834 修复了 #14897 中引入的交易中继错误，该错误导致节点有时尽管与其他节点有良好的连接，却停止接收任何新的内存池交易（参见 Newsletter #43 了解详细信息和之前的缓解措施，或 #15776 了解有关此错误及最初提议的解决方案的优秀描述）。

  • ● LND #3133 添加了对“利他”瞭望塔和客户端的支持。瞭望塔代表当前离线的客户端发送违约补救交易（正义交易），以确保这些客户端的对手方无法窃取任何资金。理想的瞭望塔在通用部署中是通过接收适度的货币奖励来发送补救交易，从而获得激励，但管理这一激励增加了复杂性——因此该完整系统的初始版本使用了更简单的利他瞭望塔，这些瞭望塔不会通过协议获得任何奖励，但仍然提供了完整的客户端和服务器组件以实现完全的强制执行。你可以为自己的通道设置一个瞭望塔，或者你可以使用可靠朋友的瞭望塔。LND 的运行时帮助文档中记录了所有必要的配置参数。开发者 Will O’Beirne 还提供了一个示例教程，帮助你设置瞭望塔、尝试违反测试通道，然后观察瞭望塔保护该通道的资金。

  • ● LND #3140 添加了在 LND 发送使用其一个或多个链上 UTXO 的扫交易时支持 RBF 和 CPFP 费用提升的功能。

  • ● LND #3134 允许用户将 LND 与 Prometheus 监控解决方案集成，以收集统计数据和发送警报。

  • ● C-Lightning #2672 添加了可以使用外部钱包资金开设通道的新 RPC。fundchannel_start RPC 启动与指定节点开设新通道，并返回一个 bech32 地址，外部钱包应使用仅包含 segwit 输入且不广播交易的方式支付该地址。当该交易已创建时，其序列化形式可以提供给 fundchannel_complete RPC 以安全完成通道协商并广播交易。或者，可以调用 fundchannel_cancel RPC 以在资金发送前中止通道设置。由于大多数外部钱包会自动广播交易，因此这些选项需要通过配置选项显式启用——但它们使得外部钱包可以更好地直接与 C-Lightning 集成。

  • ● C-Lightning #2700 限制了请求 gossip 的数量，仅从节点的部分对等方请求 gossip。这是为了继续在所有主要 LN 实现中进行的减少通过 gossip 发送的数据量的工作，因为网络已增长到数千个对等方。

  • ● C-Lightning #2699 为 fundchannel RPC 添加了一个新的 utxo 参数，允许用户指定从 C-Lightning 内置钱包中使用哪些 UTXO 来资助新通道。

  • ● C-Lightning #2696 添加了一个新的 listtransactions RPC 方法，该方法列出了程序创建的所有链上交易及其用途（设置、单方面关闭、双方关闭或防作弊）。此 PR 中的其他更改确保了所有必要数据都存储在数据库中，以提供这些结果。

  • ● Eclair #1009 允许 Eclair 搜索通过 gossip 传播的节点公告，以通过其公钥找到通道对等方的 IP 地址，以防任何对等方断开连接且其 IP 地址发生变化。

  • ● BIPs #555 添加了 BIP136，用于在区块链内的 bech32 编码交易位置。例如，链中第一个交易的位置标识符（创世区块的生成交易）是 tx1:rqqq-qqqq-qmhu-qhp。这一想法首次在两年前提议给 Bitcoin-Dev 邮件列表，建议的使用场景包括识别哪些交易包含对第三方应用程序有用的信息，例如时间戳的去中心化身份引用。