Learning from Lightning’s LND Bug – Bitcoin Magazine

garretschoenbergOctober 25, 2022

This is an opinion piece by Shinobi, a self-taught educator in the Bitcoin space and tech-minded Bitcoin podcast host.

October 9, 2022, brak We created transactions from Bitmatrix (a swap tool built on Liquid Network), broadcast them to the main Bitcoin network, and used UTXO with Tapscript multisig with a threshold of 998/999. This transaction had 998 individual signatures in the witness field, was almost 0.1 MB in size, and interestingly reused the exact same public key for each of his 999 participants in the multisig. This transaction caused massive disruption to the Lightning Network by exposing bugs in LND and btcd (an alternative client for the Bitcoin network).

The overall purpose of making this deal was to demonstrate the increased scalability of multisig scripts that Taproot has made possible. Even without using the Schnorr signature-based MuSig protocol, Taproot can enable a much larger set of multisig participants than previous versions of Bitcoin Script. This can be a bit of a nuanced discussion regarding the previous size limits of multisigs when diving into all the possible ways multisigs can be built using Bitcoin scripts, so for the sake of simplicity, it applies. Here is a brief description of previous limitations. Pay-to-script-hash (P2SH) and Pay-to-witness-script-hash (P2WSH) to multisig structures. When it comes to the standard way of doing P2SH multisig, the maximum participant size limit is only 15, and for standard he P2WSH multisig, the maximum size is 20. Using these different script operations and limiting the number of processing operations that can be performed within a single script. Violation of any of these limits invalidates the transaction.

Taproot’s implementation has completely removed these script size limits. In other words, the Taproot script size limit is only the block size limit itself. Here comes the problem with LND and btcd. The consensus rules implemented in btcd correctly removed these limits on script size, but the problem is that the code base for peer-to-peer communication also implements script size checks to provide double defense to node operators. adding layers. Blocks and transactions go through a kind of “pre-consensus” consensus validation before reaching the core consensus code that performs the appropriate validations. The logic is that double checking things adds an extra layer of defense against invalid blocks and transactions. This code was not properly updated to remove the script size limit and continues to apply SegWit’s previous script limit to Taproot transactions. So, while the actual consensus code itself would properly validate this very large Taproot transaction, the block containing it was never actually passed from peer-to-peer validation to the actual consensus validation logic. Burak Transactions.

Why did this affect LND even though many people run Bitcoin Core under LND instances? because it uses the same code as So even if the LND node was running on Bitcoin Core and the relevant block was properly validated and not stopped, the LND instance would refuse to accept the block and the main chain node would not proceed properly. If it continued, it would have stopped.

This bug was patched very quickly and to my knowledge has never been actively exploited in a harmful way, but unless you’re using external watchtowers, you should be able to All LND nodes in the channel could have their funds stolen. Since the node was stuck on that block, there was no real-time view of the blockchain. Also, if a channel counterparty sent stale channel state to the blockchain, the node was completely unaware of it and could not respond. Use appropriate penalty transactions to secure user funds. This was a very serious bug that put most of the Bitcoins on the Lightning Network at risk of being stolen. Unless you manually patch and update your nodes yourself, or personally monitor the channel so that you can manually react to it if it is closed. in old condition. I have to say that most non-technical node operators probably couldn’t.

Thankfully, this issue was not widely exploited, but it could have been very tactical by malicious actors if it had been discovered in the codebase before Burak’s transactions were pushed to the blockchain. It may have been intentionally abused in a way. An individual or a group of people can very easily open a number of channels on the network and put all the money in those channels back on-chain through submarine his swap and leave all the funds in the channel . Then, like Burak, they sent large Taproot transactions and used obsolete state to quickly close the channel. Victims don’t realize it. Even so, given the relatively low technical proficiency of his operators at many nodes, it is very likely that most did not respond in time to fix the problem manually. is expensive. penalty deal.

This bug highlights two important issues to consider. First, multiple independent implementations of Bitcoin nodes are extremely dangerous. Thankfully very few people run btcd as a serious problem node, so the impact this has had on the base bitcoin network is completely negligible, except for the very few individuals whose nodes have failed. It was something. If a miner was running his btcd, there would have been a chain split in the Bitcoin network, cutting all his btcd operators off the minority his chain and having to fix it manually. The second problem is that for her second layer above the main network, the implementation of consensus checking has to be done very carefully. This is a difficult question. Because while a Lightning node running on a Bitcoin full node can theoretically outsource 100% of this verification to that node, every Lightning node runs its own trusted full node. It’s not because I’m using it. This is unlikely to change — many users will probably continue to operate nodes that way. As such, some or all of the Bitcoin Consensus Rule checks must also be supported by Lightning implementations.