The Little Vulgar Book of Mechanics (v0.14.0) - Lightning Network I

Last updated: March 25th 2022

Just added this section to the book: Lightning Network I

Lightning Network I #

Even though this is not a book about bitcoin, I'm gonna be using Bitcoin and the Lightning Network as examples when talking about networks, cryptography, etc. enough that it's worth adding a brief introduction to both.

Of course, you should only read this section after listening to my top-notch, Oscar-winning, Pulitzer-winning instrumental thrash-death metal "music," E.g. Escape Mechanics Unlocked.

With the "music" shilling out of the way, let's get on with it:

1. Why Bitcoin?
   • Because we want to do global transactions, without a third party holding funds, without needing anything beyond a computer and internet.
   • Because of its blockchain's "gossip protocol," where every node knows about every single transaction that occurs globally, so that everyone agrees on the state of everyone's balances. I.e. for decentralized consensus.
2. Why the Lightning Network?
   • To "scale Bitcoin," because one thing the "gossip protocol" just cannot provide is fast payments.
   • Because a blockchain by itself is too slow to cover the entire world's commerce. (I.e. everything from large enterprise and government transactions, to daily and "micro" transactions).
   • To get irreversible payments in seconds without the "waiting for confirmations" issue.
   • To craft and update transaction data, and pass it around on a separate network, deferring its broadcast (to the blockchain) to the future, for near-unlimited transactions per second, so that we can pay for small stuff easy and fast.
   • Because we don't want 8-gigabyte Bitcoin blocks (which would be needed to reach e.g. Visa-level level of daily transaction volume per second), which would either collapse the Bitcoin network, or make it so that only people with lots of resources can operate nodes that validate the blockchain (i.e. centralize the blockchain.)
   • (Note: In fiat land there's also the same "layered" structure. E.g. Credit card payments are a "higher layer." The millions of credit card payments that occur each minute don't actually cause a million physical moves of physical money.)
3. Why call it a "Second layer" or "Layer 2 Protocol"?
   • To reflect the fact that it "relies on" the Bitcoin network, that it assumes features of the lower layer, i.e. Bitcoin's security building blocks (multisig, time locks, non-expiration capalitities, double-spending prevention, censorship resistance, etc.)
4. Why payment channel?
   • To work with transactions that are not committed to the blockchain, but are nonetheless secured by it (and in fact channel identifiers are based on funding transaction ids).
   • So that our off-chain transactions always refer to money that actually exists, i.e. spendable btc on the blockchain.
   • (Note: The real benefit comes from the paths that form as the network graph grows. I.e. users don't need to directly "open a channel" to each other, cos that'd be stupid. See below for the actual network behaviors, E.g. routing, path formation and finding, etc.)
5. What's the payment channel lifecycle?
   1. Establishment: A Funding Transaction on-chain for deciding the starting funds and balances based on real blockchain history. I.e. an UTXO that the participants can unlock.
   2. Normal operation: Zero or more "update" transactions created and passed around off-chain for speed, privacy, etc. E.g. for a unidirectional channel, the payer keeps making payments by creating new 2-of-2 transactions, whose outputs go to both payer and payee, with each one's quantity updated (i.e. the balance updates mentioned above.), so that when the interaction stops, the transaction is ready to be sent to the blockchain.
   3. Closing: A final Settlement transaction on-chain for recording the state of bitcoin balances to the blockchain.
6. Why use Bitcoin security primitives in the Lightning protocol?
   • To automatically ensure fairness.
   • To ensure that the right (as in morally right) transactions are broadcasted to the Bitcoin network. I.e. To avoid settlement of transactions whose state isn't the most fair, by encumbering transactions with hash locks, time locks, etc.
   • I.e. to automatically punish cheaters at the protocol level.
   • To operate in the same "trustless" manner of Bitcoin, i.e. to communicate using the Bitcoin protocol's security primitives, but without dealing with the blockchain for each action.
7. Why the Funding Transaction on chain?
   • To set initial balances so that off-chain activities during Normal operation refer to real transactions inputs found on the blockchain. I.e. Funding must come from real blockchain sats.
   • Because one or both players must fund the inputs, because the rest of their payment interaction will be entirely about updating the balances of this exact total.
8. Why multisig?
   • 2-of-2 multisig, so that no one can run away with the funds.
   • 2-of-2 multisig, to agree on off-chain balances at all times.
9. Why Time locks (CHECKLOCKTIMEVERIFY)?
   • To secure the funds, by setting a future time (expressed in blocks or timestamp) before which the script aborts execution.
   • To not allow some bitcoin to be spent before some time (or block height of the blockchain) in the future.
   • So that each subsequent off-chain "balance update" has a increasingly sooner time availability on the blockchain, so that if a cheater tries to submit an old transaction (whose balances are more convenient to him) his victim can defend by broadcasting the latest transaction, which Bitcoin's blockchain will process sooner.
10. Why the routing and "gossip protocol" stuff?
    • So that you don't have to "open a channel" (i.e. broadcast a funding and settlement transactions to the blockchain) to your final recipient whenever you wanna make a payment, because that would defeat the purpose (and it wouldn't really be a useful network, would it?)
    • To form paths by "connecting payment channels" end-to-end. I.e. if your node can construct a path A -> B -> C -> D, you can make a payment to D (or C, or B), by simply connecting to A. Note: You never "opened a channel" in this case.
    • Onion-like encrypted routing, so intermediaries don't know who the final recipient is.
    • Staggered timeouts, to route funds through multiple intermediaries safely.
11. Why refund clauses?
    • So that nothing ever gets lost. There's always a refund timeout of some kind. It's implemented in various forms. E.g. It's the Else in HTLC. It's a refund timeout in Multisig.

External Resources #

• Lightning Network In-Progress Specifications

See current full book's WIP here.