比特币技术周报丨闪电网络遭遇新安全问题，牛市或给它带来麻烦

写在前面：本周的比特币技术周报，我们会重点关注一个影响闪电网络支付的安全问题，随着比特币链上交易费用增高，其安全隐患也会随之暴露，而目前的解决方案仍存在着较大的权衡。然后我们会介绍一个新的预签名金库（ault）提议，**是常规部分内容，例如Bitcoin StackExchange的热门问答以及流行比特币基础设施的重大更新。

闪电网络遭遇新安全问题，短期解决方案或难以令人满意

本周，来自Square Crypto的闪电网络开发者Matt Corallo公布了一种窃取闪电网络（LN）节点资金的新方法。这一问题部分与一个现有众所周知的费用管理问题是重叠的，但据我们所知，这个漏洞并没有被利用，因为在过去两年中，几乎所有中继的链上交易都能相对快速地确认，即使它们仅支付了默认的**中继费率。但如果费率在很长一段时间内大幅增加，这些问题将变得更加关键。如果你担心此问题可能会影响您的通道，请与闪电网络软件开发者联系。

下面我们会详细解释这个问题：

针对闪电网络（LN）支付原子性的新攻击：Matt Corallo在和中均发布了一个帖子，其公开了一种在讨论中发现的新攻击，它允许LN承诺交易通过锚输出（anchor output）来增加CPFP（父子支付）费用。我们将通过示例来描述这种攻击：Alice使用LN通道向Bob发送一个哈希时间锁定合约（HTLC），该合约旨在通过以下任一方式解决：

1. 如果Bob公开了lt;hashgt;的原像（preimage），他就可以花掉Alice的 1 BTC；
2. 否则，在过了80个区块之后，Alice就可以将这1 BTC取回；

Alice还告诉Bob，她的目标是向Mallory付款，因此Bob使用他与Mallory拥有的通道向她发送相关的HTLC：

1. 如果Mallory公开了lt;hashgt;的原像，她就可以花掉Bob的1 BTC（在这个例子当中，我们忽略了路由费）；
2. 否则，过了40个区块之后，Bob就可以将这1 BTC取回；

尽管上述HTLC通常是在链外创建与结算的，但各方也有一笔承诺交易，可用于将HTLC承诺置于链上。单独的链上结算交易可以满足HTLC的任一条件。

例如，Mallory可以发布承诺交易，然后创建提供原像并认领Bob 1 BTC的结算交易。如果Bob在Alice-Bob合约的第80个区块超时之前，看到Mallory的原像结算交易，则Bob可以提取该原像，并将其用于从Alice那获取1 BTC（在链上或在链外）。或者，如果Bob没有看到原像结算交易，则Bob可以在40个区块之后创建自己的退款结算交易，以收回他的1 BTC，这样他也可以发起Alice的1 BTC退款（同样可以是在链上或链下）。无论是哪种情况，这都会使每个人都遵守其合约意图。

不幸的是，正如本周Matt Corallo披露的那样，Mallory似乎有一种方法可以绕过这个过程，她既可以阻止Bob学习原像，又可以防止他发送退款结算交易。

1. 原像拒绝：Mallory可通过给她的原像结算交易一个较低的费用率来阻止Bob学习原像，从而避免其被快速确认。如果Bob只是在区块链中寻找原像，那么在未确认的情况下，他将不会看到Mallory的交易。
2. 退款拒绝：由于这两笔交易发生冲突（指它们都使用相同的输入），Mallory先前广播的原像结算交易，可阻止矿工与比特币中继节点接受Bob稍后广播的退款结算交易。从理论上讲，Bob的退款结算交易可通过支付更高的费用，来取代Mallory的原像结算交易，但实际上，Mallory可以使用各种技术来防止这种替换的发生。

由于Bob无法了解到原像结算交易，也无法确认其退款结算交易，因此一旦80个区块时间过去后，Alice便可以在Alice-Bob HTLC中收回她提供给Bob的1 BTC。当Mallory的原像结算交易最终确认时，Mallory在Bob-Mallory HTLC中获得了Bob提供给她的1 BTC，这就使得Bob损失掉了1 BTC。

Matt Corallo在帖子中考虑了几个解决方案，但它们也都会遇到一些问题，或者会涉及重大的权衡：

1. 需要一个存储池（mempool）：Bob可以使用一个比特币全节点来监控比特币P2P中继网络，并了解Mallory的结算交易。一些LN节点（如Eclair）已经这样做了，这似乎是一个合理的额外负担，因为问题仅直接影响路由节点（例如Bob）。而只代表自己发送或接收付款的节点，仅会受到间接影响，因此日常用户仍可以在移动设备上运行轻量级LN客户端。不幸的是，并不是所有全节点都接收到与其他节点相同的交易，即使所有节点都工作得很好。更糟糕的是，像Mallory这样的攻击者可以使用一些技术将不同的冲突交易发送给不同的对等方（例如，将固定的原像结算交易发送给已知的矿工，但将具有至少一个相同输入的不同非结算交易发送给非矿工中继节点）。
2. 中继网络可以向交易提交者（例如Bob）提供有关冲突的信息，因此他们无需持续监控自身。这仍然会存在不良行为体的问题，比如Mallory使用目标中继，将不同的交易发送给矿工和非矿工。此外，Bob还可以为矿工或其他第三方节点支付所需的原像费用，但这需要一些人运行额外的软件，并且在部署LN协议升级时可能不那么容易。
3. 结算交易锚输出：可以重新设计链上结算交易，将其价值用于锚输出，这些输出可能是使用而增加了CPFP（父子支付）费用。这将要求这些交易变得更大（增加链上费用）并且是预先签名（降低灵活性）。这只会直接影响到那些在等待付款时单方面关闭的通道，这已经是一种可显著增加链上成本的情况，因此也是用户试图避免的。然而，提高链上的执行成本，也提高了可通过LN不受信任地发送付款的**实际价值。尽管存在这些挑战，但在撰写本文时，这似乎是最可取的解决方案。

Corallo称这是一个严重的问题，但他也指出，这一问题的后果与另一个有关链上LN交易中的费用管理已知问题类似。

截至目前，我们还尚未发现因为链上费用管理问题而引发的实际LN损失，部分原因可能是在过去两年中，很少出现持续时间足够长的大额费用峰值。

但这种好运不可能无限期地持续下去，所以这个新问题给了LN开发者一个额外的理由来优先考虑改进链上费用管理的实现。在此期间，关注攻击的节点运营商可能希望增加其clt_expiry_delta，以便使原像结算交易有更多的确认时间。在当前的LN节点中，C-Lightning的默认值为14，LND的默认值为40，Rust Lightning的默认值为72，Eclair的默认值为144。请注意，增加该值将使您的通道不太受使用者的欢迎，因为较高的值可能会导致付款被延迟。

新的多方金库（ault）契约实现

基于上周周报中提到的预签名金库（ault）契约原，Antoine “Darosior” Poinsot公布了一个名为的演示实现。这一新实现专注于存储具有多重签名安全性的多方共享资金。该协议允许各方子集通过确认信标交易（beacon transaction）来发起提款过程。如果金库的其他方反对提款，则他们有机会广播第二笔交易，将资金退还至金库中的紧急地址。如果在一定时间内没有异议，则另一笔交易可以完成资金的提取。Poinsot目前正在征求对该提案的反馈意见。

StackExchange 精彩问答

Bitcoin StackExchange是Optech贡献者寻找问题答案的**之地。在本期内容当中，我们会重点介绍一些近期最受好评的问题与答案。

问题1：？

Pieter Wuille总结了在地址中使用公钥哈希，而不是使用公钥的论点，即它可以减慢量子计算攻击的速度。他接着列举了那些所谓的论点可能被夸大并给人一种虚假安全感的原因。

问题2: ？

Murch指出，此默认策略有助于防止垃圾交易攻击，并提供了一些确定祖先交易计数的示例。

问题3: ？

Simplicity白皮书作者Russell O’Connor描述了静态分析比特币脚本程序与Simplicity语言相比所面临的挑战。

比特币主要基础设施的候选版本更新

1. 是下一版Bitcoin Core软件的**候选版本；
2. 允许测试下一个主要版本的LND客户端。
3. 是C-Lightning客户端的下一个版本的**候选版；

除了这些之外，本周Bitcoin Core还发生了一些显著变化（注：下面提到的Bitcoin Core更改，我们需要等到0.21版本才会看到，而即将发布的0.20版本不会纳入这些新功能）。

1. Bitcoin Core #15761 增加了一个upgradewallet RPC，从而允许用户在加载钱包时将其解锁并升级到分层确定性（HD）钱包。此附加功能还与多钱包兼容。
2. Bitcoin Core #17509 允许钱包GUI将部分签名比特币交易（PT）保存到一个文件中，并从文件加载PT。后续PR有望增加在GUI中进行PT签名的能力。

特别感谢

我们感谢Antoine Riard、Zmncpxj和Matt Corallo审阅这期周报的草稿，并帮助我们了解LN原子性问题的细节。如有错误，请与周报作者联系。