A severe vulnerability for the Lightning Network (LN) has been revealed with Rusty Russell, an LN dev, describing the critical bug as: “Basically, you think I am paying you but I’m not, so you happily send funds onwards.”
This has now apparently been fixed, but LN nodes were not checking if the channel is valid and they were not even checking signatures. So you could tell them whatever you wanted and they’d just trust you, or more technically:
“A lightning node accepting a channel must check that the funding transaction output does indeed open the channel proposed. Otherwise an attacker can claim to open a channel but either not pay to the peer, or not pay the full amount.
Once that transaction reaches the minimum depth, it can spend funds from the channel. The victim will only notice when it tries to close the channel and none of the commitment or mutual close transactions it has are valid.”
Russell says the specification did not specify the need to carry these extremely basic checks. He says: “It did NOT require the receiver to actually check that the transaction is the one promised by the funder: both the amount and the actual scriptpubkey.”
There’s about $7 million worth of bitcoin in the Lightning Network, with another LN dev stating earlier this month: “We’ve confirmed instances of the CVE being exploited in the wild.”
How this extremely basic matter passed checks for now nearly two years, is unclear, but LN is pretty small with it barely having more funds than the tokenized bitcoin which runs on ethereum.
Yet there are three implementation teams and quite a few devs, but no one wondered for years if they should be verifying whether a channel is valid or not.
Even Russell himself appears to have come across it somewhat accidentally while testing “multiple new proposed features [that] add new complexities.”
That feature is presumably what they call Hyperloop, which in plain english is better called gatekeepers.
This is still work in development, but basically instead of you just closing a channel, you send it to the exit gate, which then collects all these other channels that want to close and so bundles them into one transaction.
Bitcoin has the ability to include within what is plainly called a transaction, hundreds of actual transactions from one address to hundreds of different addresses.
One such bundled transaction is about 20 bytes times however many actual transactions, while what is commonly called a simple transaction from just A to B is about 200 bytes.
So you might want to send it to the exit GATE to save fees with the gatekeeper then sending it to the actual blockchain addresses.
This can be done through an entry gate as well, where you “send” your bitcoin to the gatekeeper that then loops you into the Lightning Network and so gives you a channel and all the rest.
They claim all this is trustless, but they haven’t solved the double spending problem, so LN is trust all the way down.
That’s because Lightning is its own network, with its own transactions which are not organized in a blockchain with proof of work that enforces node consensus in regards to validity and double spending.
What we have on LN instead is a proof that a blockchain address has x bitcoins. That’s now. As the vulnerability shows, LN did not have even that. They’re now claiming this is fixed, but it’s a bit curious that such absolutely foundational capability was not there for two years.
That does raise the question whether they can actually indeed prove the validity of the claim or statement that the x address does have x amount of locked bitcoin.
It raises this question because obviously you can read the blockchain and see it is locked, but it might get complicated with a network setting especially with gatekeepers.
Anyway assuming you can prove this aspect in an indisputable way in a network setting, you give this proof to the merchant who now thinks you have paid him.
You now give this same proof to another merchant, and he too thinks you have paid him because there’s no consensus in LN, nodes don’t know what other nodes are doing, no one is putting a stamp of approval on anything like proof of work does in a blockchain.
The way they address this double spending is by having a Watchtower that enforces a rule which says if you spend the same transaction again, you’re punished by the merchant having the right to all your bitcoin.
We haven’t looked at how this Watchtower works exactly to conceptually see if they can be fooled by them being told one thing and the merchant another.
It’s unlikely, but there’s no consensus here. Save for what the blockchain says, all the aspects of the rest can presumably be changed by a coder modifying his own node to give it whatever rules it wants.
Now the merchant is running his own node with the “official” rules, but an attacker needs to fool just his node to manipulate data, instead of all of the 4.5 million asics that currently secure the rules of the bitcoin network.
That’s especially important when it comes to Watchtowers. Just one of them needs to be malicious to reck havoc because they can apply whatever rules they please once this leaves the blockchain, which conceptually it does with the very first transaction on the Lightning Network.
The Watchtower does not even have to be malicious. Some accidental data corruption and you have the whole thing crashing down because the Watchtower/s become systemic.
Much of this is not being exploited now because no one really uses LN, but if a prominent exchange, for example, begun accepting bitcoin deposits through LN, then pretty smart people might show just how secure all this is.
Hence why LN was conceptualized more for micro-transactions, tiny payments of a satoshi or so with little incentive for anyone to bother stealing them.
Now however this has been turned into some sort of proposed blockchain replacement when no new genius has come out to solve the double spending problem without a blockchain with some sybil resistance mechanism.
The “geniuses” instead provided a network where for almost two years nothing whatever was verified.
Copyrights Trustnodes.com
