This is an editorial by Shinobi, a self-taught Bitcoin educator and host of the tech-oriented Bitcoin podcast.
On October 9, 2022, burak Created and broadcasted by Bitmatrix (a swap tool built on the liquid network) Transaction to the main Bitcoin network, where UTXO is spent using Tapscript multisig with a threshold of 998 out of 999. This transaction had 998 individual signatures in the witness field, was about 0.1MB in size, and kind of funny, reusing the exact same public key for every one of 999 participants in multisig. This deal caused a major disruption to the Lightning Network by exposing a bug in LND And the btcd (Alternative client of the Bitcoin network).
The whole purpose of conducting this transaction was to demonstrate the improved scalability of multi-signature scripts made possible by Taproot. Even without using Schnorr’s signature MuSig Protocols, Taproot can enable larger groups of multitasking sharing than previous versions of Bitcoin Script. This can be a bit of a subtle discussion regarding the prior sizing of multisig if you dive into all the possible ways you can create multisig using Bitcoin Script, so for the sake of simplicity I will simply discuss the previous limits applied to Pay for the retail script (P2SH) and Pay for retail script witness (P2WSH) multisig constructions. When it comes to the standard way of doing P2SH multisig, the maximum participant size is only 15, and in the case of standard P2WSH multisig the maximum size is 20. These use different scripts, and the limitations in the number of processes allowed in a single script scope . Violation of any of these limits will render the transaction invalid.
With the implementation of Taproot, the script size limits have been completely removed, which means that the only limits with the Taproot script size are the block size limits themselves. This is where the problem comes in regarding LND and btcd. The consensus rules implemented in btcd correctly removed these limits regarding script size, but the problem is that the peer-to-peer communication code base also implemented checks on script size to add a double layer of defense for contract operators. Blocks and transactions will go through some kind of “pre-unanimous” consensus validation before even accessing the underlying consensus code that does the correct validation, and the logic is that double-checking things add additional layers of defense against invalid blocks or transactions. This code has not been updated properly to remove script size limits, and continue to enforce previous script limits for segwit Against Taproot Transactions. So, while the actual consensus code itself would have correctly validated a very large Taproot transaction, the block containing it was not actually passed from peer-to-peer validation to the actual consensus validation logic, which means that All btcd nodes are parked in the block including the Burak deal.
Why does this affect LND, given that many people run Bitcoin Core under their own LND instance? That’s because LND uses the same code that btcd uses to receive and process blocks. So even if your LND node was running on top of a Bitcoin Core, which would have validated the relevant block correctly and not stopped, your LND instance may refuse to accept that block and stop even though the main chain node continues to progress correctly.
This bug was fixed very quickly, and to my knowledge it was not actively exploited in a way that does any harm, but this left every LND node on the Lightning Network open to stealing money in channels unless they were being used externally. Control tower. Because the node was parked in that block, it did not have a real-time view of the blockchain, and in the event that the counterparty of the channel were to send an old channel state to the blockchain, it would be completely unaware of it and unable to respond with the appropriate penal transaction to secure the user’s funds. This was a very serious mistake that put a large proportion of the Bitcoin on the Lightning Network at risk of theft unless users were manually debugging and updating their nodes themselves, or personally monitoring their channels so that they could manually respond in the event of a shutdown. with an old country. I must say that the vast majority of non-technical node operators may not have been able to do this.
Fortunately, this issue has not been widely exploited, but if this was discovered in the database before the Burak transaction was pushed to the blockchain, it was intentionally exploited by bad actors in a very tactical way. An individual, or a group of people, can very easily open a large number of channels on the network and exchange all the money in those channels back to themselves on the chain through submarine swap, leaving all the money in the channel on the other side, then sending a big Taproot transaction like Burak did, and immediately shutting down their channels using an old case. Victims would not be aware of this, and even if they were, given the relatively low technical proficiency of many node operators, it is very likely that most people were not able to respond in time to manually correct the problem with a penalty transaction.
This error highlights two important issues to consider. First, multiple independent executions of Bitcoin nodes can be very dangerous. Fortunately, almost no one operates btcd as a node for anything serious, so the impact of this on the Bitcoin core network was something that could be completely ignored, except for a very small handful of individuals whose nodes simply stopped. If miners were running btcd, it could very easily have resulted in a chain split on the Bitcoin network that would have removed all btcd operators from a minority chain that would have required manual intervention to correct. The second issue is that in the case of the second layers above the main network, consensus checks must be carried out very carefully. This is a tricky problem, because while any Lightning node running on top of a Bitcoin full node can theoretically simply outsource 100% of this validation to that node, not all Lightning nodes benefit from their trusted full node. This is not likely to change – many users will likely continue to run nodes in this way, so checks for some or all of the Bitcoin consensus rules should also be supported in Lightning apps as well.
Moving forward, I hope this is a wake-up call to how important it is to ensure that consensus validations are synchronized with each other across software in this space, because without this synchronization between everything there is really no single coherent Bitcoin network. Everyone should be very happy that this didn’t result in a massive exploit across the entire network, but people should be aware of how serious this issue could be had things not been done the way they did.
This is a guest post by Shinobi. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
#Learning #LND #Bug #Lightning #Bitcoin #Magazine