I read Melik Manukyan’s piece yesterday, and thought it was important to add a few things. Melik uses TCP/IP and ethernet as analogies to how the Lightning network aims to decrease load on the blockchain. It’s so intuitively easy… this is how I originally thought about it as well, but a few important details have come up in further research.
Lightning Network enables Unicast Transactions in Bitcoin. Lightning is Bitcoin’s TCP/IP stack._It has recently come to my attention that there is a great deal of confusion revolving around the Lightning Network…_medium.com
Before we get too deeply into this: I am not deep in the bowels of the lightning or BTC project. I am putting together my best guess as to how things really are based on reading and talking to people. I may have missed things. If you think I have, please tell me!
I have not yet found an analogy that captures the most important details of Lightning, so I will try to point out the details that I think the TCP/IP metaphor misses. A key part of TCP/IP is that routing is best-effort and the only reason it works is that nodes have no incentive to cheat, and mis-direct 10% (or 100%) of the packets. There’s no money to be made by doing this.
With Bitcoin, there is every incentive to cheat. If I send Alice sends Bob 10BTC to give to Charlie, Bob can easily just have a nice holiday instead. If Bob is a well-known bitcoin clearinghouse like Coinbase, they’ll lose business as a result (but probably not as much as you might expect). In order to remove “trust” from the equation, Lightning requires both parties in a connection to “put up collateral”, ensuring that they do not cheat. To open a connection “on the Lightning network”, an on-chain transaction is created and broadcast by both parties that sets up an “escrow account” known as a bidirectional channel. Let’s say they both put in 1BTC. Both parties now can update the “balance”, which starts out as equal. Alice can send Bob 0.1BTC by changing the balance to be 0.9BTC for Alice, and 1.1BTC for Bob. They can send these back and forth these mutually-signed “updates” (really just transactions that don’t get broadcast to the network). When either of them “wants out”, they broadcast the transaction to the network, and the blockchain closes out the escrow account.
What if after Alice signs the “0.1BTC to Bob”, she then broadcasts the old update, the one where she hasn’t sent the 0.1 BTC? Bob has to watch the bitcoin network, and if he sees that transaction, he has to quickly send the “latest” version of the transaction, which will invalidate Alice’s malicious one. If Bob’s node is down, or connected poorly, Bob is out of luck. Sorry Bob.
Let’s go back to the “hub/switch” analogy. In Lightning, in order for Bob to route Alice’s 10BTC to Charlie, Bob needs to have at least 10BTC in the Alice-Bob channel and the Bob-Charlie channel. That means that Bob needs to have 20BTC locked up — twice the amount he’s trying to send. Bob can, in principle, “settle up” at any time, but having 20BTC lying around just in order to facilitate free transactions between Alice and Charlie seems like a steep price. I certainly wouldn’t want 20BTC locked up just to help people send money. If I were Bob, I’d probably happily do it for a few percent of the transaction… but that’s not the point!
Circling back, it should be pretty clear at this point that TCP/IP is perhaps a good analogy for the possible shapes of the lightning network, but it fails to capture some important aspects to the real-world use cases. It is unclear to me how we can even “get there from here”. Renting space in a NOC isn’t cheap, but once you’re in, it’s basically all-you-can eat in terms of network volume. Not so with lightning, every time you want to “up your limits”, you have to put more and more bitcoin aside in order to service the open connections.