Fortunately, this issue was not widely exploited, but had this been discovered in the codebase before Burak’s transaction was pushed to the blockchain, this could have been intentionally exploited by bad actors in a very tactical way. A person, or a group of people, could very easily have opened a large number of channels on the network and exchanged all the money in those channels back to themselves on the chain through a submarine exchange, and put all the funds in the channel on the other side, and then sent into a large Taproot transaction like Burak did, immediately shutting down their channels using an outdated state. The victims would not even be aware of it, and even if they were, given the relatively low technical expertise of many node operators, it is very likely that most would not have been 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 implementations of Bitcoin nodes can be very dangerous. Fortunately, almost no one runs btcd as a node for anything serious, so the effect this had on the Bitcoin base network was something that could be completely ignored, except for a very small handful of individuals whose nodes simply stopped. If miners had run btcd this could very easily have resulted in a chain split on the Bitcoin network which would have taken all btcd operators off on a minority chain which would have required manual intervention to correct. The other problem is that when it comes to other layers above the main network, implementations of consensus checks should be done very carefully. This is a tricky problem, because while any Lightning node running on top of a Bitcoin full node could in theory simply outsource 100% of this validation to that node, not all Lightning nodes use their own trusted full urge. That is unlikely to change – many users will in all likelihood continue to operate nodes in such a way, so to some extent checks on some or all of the Bitcoin consensus rules must also be supported in Lightning implementations.
Going forward, I hope this is a wake-up call to how important it is to ensure that consensus validation checks are all in sync with each other across software in this space, as without that synchronicity between everything, there is not actually a uniformly coherent Bitcoin Network. Everyone should be very happy that this didn’t result in a massive network-wide exploit, but people should be aware of how serious this problem could have been if things hadn’t worked out the way they did.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.
