Lightning Network User Loses Funds

The Lightning Network (LN) has encountered its first problem leading to a loss of funds for an individual who faced a somewhat edge case of having their channel database corrupted.

“A user on the LND slack who had a corrupted channel database, restored an old backup, then closed his channels.

Because the backup was out of date, his node broadcast old channel states and his channel partners’ nodes detected this as fraud and published the penalty transactions,” Chris Rico, a bitcoiner recounting the event, says.

When the old channel was broadcasted, LN’s if/then code went into gear, punishing the person because it assumed it is a hacker trying to steal funds.

As can be seen above, the code assumes this is a malicious actor, but in this case it wasn’t, it was just a poor guy who had his database corrupted and made a mistake.

He should have had backups of the current state (although just how feasible that is remains unclear), rather than restoring old states, with some saying old states should be auto-deleted. But let’s understand what’s happening here.

The Lightning Network operates through somewhat simple smart contract functionalities available in bitcoin’s script language.

To begin with, you and your friend use a time-locked multisig transaction which contains the amounts that can be spent.

Then, instead of actually moving those coins, you create a tap of sorts whereby you tell your friend you will pay him x and give him a hash signature to prove you mean it.

You can do this many times, with the real funds of say 10 bitcoins staying 10 bitcoins, but if you promise to pay him 5, a database of sorts is created which say you really have only 5 coins now because the other 5 is committed.

This is all algorithmic so it’s not as weak as a promise. But let’s now say you pay another 2 bitcoins, leaving you with just 3 more and 7 spent, then another two bitcoin, leaving you with 1 more and 9 spent.

As stated each of these spends is an update on the database, but what if you tried to be smart and broadcast the old state which says you have spent only 5 bitcoin, rather than the latest one?

Well then your friend can take all of your bitcoin, including the one you have left, but that’s only if he’s kept all these signatures for all these transactions.

So when the LN user broadcasted the old state, the network thought he was pretending he had not spent the rest, so it took all his money.

He of course probably didn’t know of this game theoretical aspect of LN, so intuitively did what you’d do in most situations and just restored a backup. Moreover in this case his friends were nice and sent him back the funds.

Conceptually however you can think of many very edge cases where it is not friends doing it and where the network would not take his funds because perhaps they have lost those signatures.

Which means one needs to be very careful with what LN wallet one uses because all this game theory is incorporated in the wallet code itself and automatically performs what needs to be done.

A bad design, therefore, can easily lead to lost funds. But it isn’t clear just how bad the design was in this case as if you delete old states, you have to trust your friend does too, or he gets a free lunch.

What is clear however, as we have stated many times and as developers have stated, is that LN is just out. So it needs some time for edge cases to arise and be refined, bugs straightened out and so on, because lab testing and theoretical conception can only go so far.

Use LN therefore only with great caution, and only with amounts you wouldn’t care to lose, certainly for the next few weeks, but at least for the next few months.