A Lightning Network user reportedly lost 4 Bitcoin, but don’t call it weird.
The original design of Bitcoin had a user submit a transaction to any node. That node would share the transaction around the whole network, and the transaction would almost always be included in a block that is secured with proof of work. Subsequent blocks would be found, each one increasing the amount of work needed to reverse the payment. This setup created an abstractly beautiful game theoretic solution where a bad actor would have incentive to support the network instead of attack the network. In the literature we have called information that is included in a block as part of a growing blockchain to be under a Nakamoto Consensus.
The Lightning Network supports metadata associated to the blockchain, though this metadata is not secured by a Nakamoto Consensus. In theory, this metadata could be secured and updated on chain from time to time. In practice, this can be costly/difficult due to on chain restrictions of Bitcoin.
How the Lightning Network works
Lighting wallets can be either custodial or non-custodial. A custodial wallet involves a third party that controls the units being exchanged. This third party must be trusted. Let’s review Alice using a non-custodial Lightning wallet, and what happens technically during the Lightning Network use.
Say Alice wants to buy a used laptop from Bob who wants a $40 payment on the Lightning Network in exchange for the laptop. Alice could buy $50 of Bitcoin, she could then open a channel with Frank who runs a well connected Lightning network node. Alice will pay a network fee for this and now has a $49 credit on the Lightning Network. Bob then provides a QR code to invoice for the laptop. Alice will click pay, and if things go well the Lightning Network will find a route to pay Bob. Such a route may deduct her balance with Frank, who may then pay Carla, who routes the payment to Bob. Now Frank and Carla may take a little fee, but this fee is generally negligible. It’s also possible that no route can be found between Frank and Bob. In such a case, Alice would need to open a channel with a different node of the network, tying up much more than the $40 that Alice budgeted for the laptop.
Let’s say the payment goes through and Bob hands over the laptop. Now Alice will have a $9 credit on the network. She can spend this as long as a route can be found to the merchant. Let’s lay that Alice sells some old books for Lightning Network payments of $15, then she settles a bill after a nice meal at a restaurant by paying her lunch companion $11. Alice will then have $13 credit on the channel with Frank. All these payments will not be on a blockchain. Alice could choose to close the channel, which would then provide her with $12.50 of Bitcoin after fees.
Replacing Nakamoto Consensus game theory with the Prisoner’s Dilemma
If Alice’s computer goes down, there could be a complication. Alice’s computer could forget about the $11 lunch payment. In that case if Alice tried to close the channel she would then try to claim $24. The lunch companion’s computer could then notice the discrepancy and publish a punishment transaction. A punishment transaction proves that the channel state being claimed is not current, and punishes the submitter for trying to claim too much money.
In my view, this is a dirty little secret of the Lightning Network. The Lightning Network replaces the elegant game theory that a Nakamoto Consensus affords with a revamping of the common prisoners dilemma. A punishment transaction is just a reincarnation of the tit-for-tat strategy used in the prisoners dilemma.
How the 4 Bitcoin were lost
When Reddit user ZipoTm reported the loss of 4 BTC worth over $30,000 at the time, it should not be considered weird as the discussion suggests. This should be understood to be the operation of the Lightning Network as designed.
According to reports, the node went down. Many channels were used very often, which means that it is difficult to near impossible to back up these channel states. There were reports that when the node was restarted there were syncing errors reported. In such a case, the Lightning node operator can either wait for the counter party to close the channel, or they can force close the channel which will risk a punishment transaction and the loss of funds.
Lightning’s problems that Satoshi Nakamoto solved with Bitcoin
In writing this article, other flaws of the Lightning Network were suppressed so that this issue could be clearly brought up. There are many other pitfalls of the Lightning Network. Satoshi Nakamoto’s paper allowed for certainty of a global digital ledger. The Lightning Network only uses Nakamoto’s result when opening and closing channels. Everything that happens in between is subject to all the issues that were solved in Nakamoto’s paper. The Lightning Network does not provide an adequate substitute for Nakamoto’s result. Hopefully, users will understand these facts sooner rather than later.
