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

Last updated: March 29th 2022

Just updated this section of the book: Lightning Network I

Appendix #

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 those with enterprise and industrial-grade resources could operate nodes that validate the blockchain. I.e. It would price average people out of blockchain validation. I.e. it would 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. UTXOs that either of the channel partners 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 (i.e. the blockchain transaction structure and Bitcoin Script language) 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.
    • To automatically penalize 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.
    • So that channel partners don't need to trust each other. They only need to trust the protocol.
  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, and thus this funding is called the "channel capacity."
  8. Why 2-of-2 Multisig?
    • So that no one can run away with the funds.
    • 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 Public channels?
    • To implement payment forwarding. I.e. To have an actual payment network.
    • So that not every node in the network has to "open a channel" (i.e. broadcast a funding and settlement transactions to the blockchain) to the final recipient whenever they want to make a payment, because that would defeat the purpose, as it wouldn't be a useful network. (It'd just be a conceptual collection of separate 1-to-1 pairs/connections.)
    • 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.
  11. Why Onion-routing?
    • So that intermediaries (i.e. those who "forward" payments) don't know who the original sender and final recipient are.
    • So that intermediaries forward payments without knowing which other nodes, besides their predecessor or successor, are part of the path.
    • So that intermediaries don't even know what their position is in the path.
    • Staggered timeouts, to route funds through multiple intermediaries safely.
  12. Why Commitment transactions?
    • To implement refund clauses during Establishment, so that nothing ever gets lost, and channel partners don't have to trust each other. So that before broadcasting the Funding transaction, you ask your peer to sign a transaction that pays your whole initial funding back to you.
    • Because you don't want to put your money in the 2-of-2 multisig Funding transaction without having a refund transaction first, because you'd then be vulnerable to the other end.
    • To avoid reverting back to trust.
    • To commit the latest balance distribution each time it changes during Normal operation. I.e. each time a payment is sent.
    • (Note: These transactions are then the precise technical meaning of "sending a payment through the Lightning Network.")
    • So that if your channel partner disappears, you have a transaction you can broadcast to the blockchain, to get your money back.
    • It's implemented in various forms. E.g. It's the Else in HTLC. It's a refund timeout in Multisig.
  13. Why timelock delays and revocation secrets?
    • Timelock: To prevent and punish cheaters who publish old commitment transactions to the blockchain.
    • Timelock: To prevent those who cheat by publishing old commitment transactions, from being able to immediately use the stolen funds, giving a window of time to the cheated to move them first.
    • Timelock: To give the cheated a chance to claim the whole balance of the cheater.
    • Revocation secret: To allow either party to bypass the timelock. So each partner has half of the secret and, with each balance update, one of them asks for the other's half, before signing the new commitment transaction.
    • To eliminate profit incentives for cheating.
  14. Why a required reserve for each channel balance?
    • So that the cheating penalties always actually hurt. I.e. so that there's always enough "skin in the game."
  15. Why Full Lightning Node (or 3rd-Party) + Self-managed (or custodial)?
    • (3rd-party Node, Custodial wallet) for when you don't want to maintain a node, and don't care about someone else holding your keys. I.e. you only care about convenience.
    • (3rd-party Node, Self-managed wallet) for when you don't want to maintain a LN node, but you want to manage your keys.
    • (Full Node, Custodial wallet) for when you want to maintain your own LN node, but you don't care about managing your own keys. (I'm failing to imagine this use case.)
    • (Full Node, Self-managed wallet) because you want full control, zero asking for permission for anything ever. Mr. Sovereign Individual.

External Resources #

See current full book's WIP here.