Hebrew University professors have disclosed another attack on Lightning Network, but that is far from the first problem that BTC’s alleged “scaling solution,” has experienced this year. Five years after the network launched, Lightning Network is still in a perpetual beta phase wrought with bugs, CVEs and frequent zero-day attacks that Bitcoin was created to solve in 2008. But they persist on the network designed to steal Bitcoin transactions, process them for free by avoiding proof of work, and the engineers claim Lightning solves Bitcoin’s supposed short-comings by (wait for it...) adding exponential complexity on a separate ledger. What is Lightning Network? If you’re unclear how Lightning Network is supposed to work, LN is a ledger of payment channels that parenthetically connect to the small block BTC network for occasional settlement. While BTC coins are locked in a Segwit address and issued into a channel by a two-way peg and controlled by smart contract rules, tokenized “IOUs” of BTC units can be traded back and forth and kept on a separate tally (like a bar tab) that can be settled eventually on the BTC blockchain. First debuted in 2015, the Lightning Network was supposed to move from concept to full operation in 18 months, but now, five years later, competing implementations from Lightning Labs and Blockstream are still not stable enough for common use. Large transactions are still more likely to fail than to succeed, and in order to transact without the permission and infrastructure of a large custodian, a Lightning Network user needs to have RAID storage, and a bevy of premium hardware to run a node. And even after investing lots of time and money in hardware, the network itself is plagued with unpatched attack vectors. Let us not even mention the fact that Lightning Network was designed under the premise that BTC Core nodes allegedly needed to remain cheap and easy to run for “decentralization.” What attacks can we expect on Lightning? Well, bitcoin’s proof of work solves the Byzantine fault of a consensus network operating in an adversarial environment. Unfortunately, small blockers do not think it is fair that Bitcoin is governed by honest nodes who render proof of work to the network. So, In order to make sure everything other than the Bitcoin protocol is tested, computer scientists (and I use that title loosely) have created exponentially more complex pathways to transact so that the obsolete BTC network can be governed by people who have no money, do not want to work, and believe that it is their job to seize the means of production so that sybil attacks remain inexpensive for anonymous users with bad internet connections. Unfortunately, hamstringing network parameters on the BTC network has exponential spill-over costs on the separate network where they are trying to deploy all of their lower value transactions: Lightning Network. The complexity of the network and reintroduction of off-chain sybils in place of honest nodes creates opportunities for zero day exploits, time-dilation and eclipse attacks, refund denial attacks, congestion attacks, and now what Hebrew University of Jerusalem is referring to as a “Flood and Loot Attack.” How do we flood and loot Lightning Network? In short, the attack focuses on the connection of the BTC network to the Lightning Network and leverages the fact that settlement times are slow. Lightning is designed to close channels and settle transactions to the blockchain in the event of a fatal error on Lightning. But it is also designed not to do this too often, because the BTC network is very easily overloaded. Transactions pass from node to node on Lightning Network using hashed time-locked contracts. If the attacker sets a deadline into too many transactions for the contracts to manage, channels start closing rapidly—causing lots of on-chain BTC transactions, and leaving contract funds up for grabs. If that was not simple enough, an attacker would only need to volley the attack at 85 Lightning nodes in order to guarantee success in the “looting.” With 95% of Lightning channels accepting incoming connections, attackers could potentially connect to nearly every time-locked contract on the entire network and empty them of funds! While the researchers said there are some potential fixes on the way, the attack is rooted in the fundamental way that transactions occur on the Lightning Network, and therefore, “eliminating the risk entirely seems to be a complicated task.” Of course, none of this would be a problem if the BTC network was using the bitcoin protocol, which scales by design—a design only implemented by Bitcoin SV (BSV). As for the obsolete BTC network, the developers cannot get enough of the idea that transactions should be occurring on a separate network. Meanwhile, it seems people agree that a second network is a good idea as long as it is not Lightning! Ethereum is the “other network” of choice when it comes time for small blockers to send cheap BTC transactions, and as such, there is over four times as much BTC locked up in Ethereum contracts than are staked on the Lightning Network. Suggestion for small blockers and Ethereans: Tokenize BTC and ETH on BSV, and be happy!