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. Continue reading…