这是由比特币领域自学成才的教育家和面向技术的比特币播客主持人 Shinobi 撰写的一篇观点社论。
大约一个月内，btcd/LND 第二次出现漏洞，导致它们偏离了比特币核心的共识。 Burak 再次成为触发此漏洞的开发人员——这一次显然是故意的——而且，这又是用于解析共识层之上的比特币交易的代码的问题。正如我在我的文章中讨论的 关于先前的错误 在 Taproot 之前，Burak 触发了交易中的脚本和见证数据的大小。随着 Taproot 的激活，这些限制被删除，只剩下对块大小限制本身的限制来限制各个交易的这些部分。最后一个错误的问题是，尽管 btcd 中的共识代码已正确升级以反映此更改，但处理点对点传输的代码（包括在发送之前或接收时解析数据）并未正确升级。因此，在实际通过验证共识之前处理块和交易的代码使数据失败，从未将其传递给共识验证逻辑，并且有问题的块从未被验证。
这次也发生了非常相似的事情。代码库点对点部分的另一个限制是错误地对见证数据实施了限制，将其限制为最大块大小的 1/8，而不是整个块大小。布拉克制作了一个 交易 见证数据只有一个重量单位超出了严格限制，btcd 和 LND 节点再次停滞在该区块高度。该交易是非标准交易，这意味着即使根据共识规则它完全有效，但根据默认内存池策略它是无效的，因此节点不会通过网络中继它。完全有可能将其开采成区块，但唯一的方法是将其直接提供给矿工，这就是 Burak 在 F2Pool 的帮助下所做的。
这确实说明了一点：任何旨在解析和验证比特币数据的代码都必须经过严格审核，以确保其符合比特币核心的功能。该代码是节点实现的共识引擎还是只是为闪电节点传递交易的一段代码并不重要。第二个错误是 字面上就高于上个月的水平 在代码库中。甚至闪电实验室的任何人都没有发现它。 AJ Towns 于 11 月 998 日报告了这一问题，两天前，Burak 的 999 中的 10 多重签名交易触发了最初的漏洞。它在 Github 上公开发布了 XNUMX 个小时，然后被删除。随后进行了修复，但未发布，目的是在 LND 的下一个版本中悄悄修补该问题。
现在，这是针对严重漏洞的相当标准的程序，特别是对于像 Bitcoin Core 这样的项目，此类漏洞实际上可能会对基础层网络/协议造成严重损害。但在这种特定情况下，它给 LND 用户的资金带来了严重的风险，并且考虑到它实际上紧邻具有相同风险的先前错误，因此它被发现和利用的机会非常高，正如布拉克所证明的那样。这就引出了一个问题：当涉及到这样的漏洞时，安静补丁方法是否是正确的方法，这些漏洞可能会让用户面临资金被盗的风险（因为他们的节点无法检测旧的通道状态并对其进行适当的惩罚）。
正如我在关于最后一个错误的文章中所说的那样，如果恶意行为者在善意的开发人员之前发现了这些错误，他们就可以在战术上为易受攻击的节点打开新通道，将这些通道的全部内容路由回自己，然后利用了该错误。从那里，他们将控制这些资金，并且能够以初始状态关闭通道，实际上使他们的资金翻倍。 Burak 以讽刺的方式积极利用这个问题所做的事情实际上保护了 LND 用户免受此类攻击。
一旦被利用，用户就可以接受来自先前存在的、与他们已经有开放通道的同行的此类攻击，但他们不再能够成为新通道的专门目标。他们的节点被停滞了，永远不会通过某人试图在导致其节点停滞的区块之后打开的通道来识别或处理付款。因此，虽然它并没有完全消除用户被利用的风险，但它确实限制了他们已经拥有频道的人的风险。布拉克的行动缓解了这种情况。就我个人而言，我认为针对该错误的这种类型的操作是有意义的；它限制了损害，让用户意识到风险并使其得到快速修补。
LND 并不是唯一受到影响的事情。液体的 挂钩过程也被破坏，需要更新联邦工作人员来修复它。 Rust 比特币的旧版本 也受到影响，这导致停顿影响了一些区块浏览器和 electrs 实例（Electrum 钱包后端服务器的实现）。现在，除了 Liquid 的挂钩最终在时间锁到期后将资金暴露给 Blockstream 持有的紧急恢复密钥之外——而且，实际上在 Blockstream 窃取这些资金的抢劫式电影情节中，每个人都知道该追捕谁——这些其他人问题在任何时候都不会使任何人的资金面临风险。此外，Rust Bitcoin 实际上已经在新版本中修复了这个特定的错误，这显然没有导致与其他代码库的维护者进行任何沟通以强调此类问题的可能性。只有网络上对该错误的积极利用才广泛暴露出多个代码库中存在该问题。
当涉及到比特币第 2 层软件中的此类漏洞时，这会带来一些大问题。首先，这些代码库的安全漏洞审核的严重程度，以及与新功能集成相比如何确定优先级。我认为很明显的是，考虑到第二个错误甚至没有被代码库的维护者发现，安全性并不总是被优先考虑，尽管它实际上就在上个月发现的第一个错误旁边。在出现一个使用户资金面临风险的重大错误之后，是否没有对该代码库进行内部审计？是项目之外的人发现的吗？这并不表明保护用户资金比构建新功能来吸引更多用户更重要。其次，这个问题已经在 Rust Bitcoin 中得到了修补，这一事实表明不同代码库的维护者之间就此类错误缺乏沟通。这是很可以理解的，因为完全不同的代码库并不会让发现其中错误的人立即想到，“我应该联系其他使用完全不同的编程语言编写类似软件的团队，警告他们存在此类错误的可能性。”你在 Windows 中没有发现错误，然后立即想到向 Linux 内核维护人员报告该错误。然而，比特币作为全球网络分布式共识的协议是一个非常不同的野兽。当谈到比特币软件的漏洞时，也许比特币开发人员应该开始沿着这些思路思考。尤其是在解析和解释与共识相关的数据时。
最后，也许当涉及到像闪电这样的协议时，它依赖于始终观察区块链以便能够对旧的通道状态做出反应以维护安全性，数据的独立解析和验证应该保持在绝对最低限度——如果没有完全删除并委托给比特币核心或直接从中派生的数据。核心闪电就是以这种方式构建的，连接到比特币核心的实例，并完全依赖于该实例来验证区块和交易。如果 LND 以同样的方式工作，btcd 中的这些错误都不会影响 LND 用户，使他们的资金面临风险。
无论以哪种方式处理事情——要么完全外包验证，要么简单地最小化内部验证并更加小心地处理它——这一事件表明，在处理第 2 层软件如何处理与共识相关数据交互的问题时，需要做出一些改变。再次，每个人都非常幸运，这不是被恶意行为者利用，而是被开发人员证明了这一点。话虽如此，比特币不能指望运气好，也不能指望不存在恶意行为者。
开发者和用户应该专注于改进流程，防止类似事件再次发生，而不是像烫手山芋一样互相指责。
这是 Shinobi 的客座帖子。 所表达的观点完全是他们自己的观点，不一定反映 BTC Inc 或比特币杂志的观点。
