The Little Vulgar Book of Mechanics (v0.14.2)

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

Last updated: April 9th 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:

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.
Why the Lightning Network?
- To "scale Bitcoin" off-chain, because one thing a "gossip protocol" on-chain 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.)
- Because scaling "off-chain" is also a backwards compatible approach, which keeps large scale adoption stable.
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.)
Why payment channels?
- To establish an A -> B relation between nodes, because B is the final recipient in an economic relationship, and/or a well-connected and well-funded node in the network (see "Why payment forwarding?" below).
- 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.)
Why a three-stage 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.
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.
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."
Why 2-of-2 Multisig?
- So that no one can run away with the funds.
- To agree on off-chain balances at all times.
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.
Why payment forwarding?
- To form paths by connecting payment channels end-to-end, 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. (It'd just be a conceptual collection of separate 1-to-1 pairs/connections.)
- So that A can send "micropayments" to D, i.e. send payments smaller than the on-chain fees involved in opening a new A -> D channel.
- (WARNING: Physical analogy) So that you don't have to build a road from A to D (and thus pay the costs involved in such building) when there already exists an A -> B -> ... -> D road.
Why hash time-locked contracts (HTLC) and payment secrets?
- To implement an atomic ("all or nothing" payment forwarding, time-locked refunds, no "half-paid" states, no race conditions), trustless (no ability to steal, or do ransom attacks, time-locked refunds), two-round multi-hop payment channel network.
- To add a deadline to payment forwarding contracts, after which they become invalid and senders are refunded, to avoid "No one can steal from anyone, but funds locked forever in a multisig, cos someone is being an asshole / MIA / etc."-type situations. I.e. So that payment forwarding is "all or nothing," i.e. atomic.
- To implement a fairness protocol, which requires, i.e. specifies as condition of payment, that intermediaries relay a hash H of a random secret R (called a "payment secret" or "payment preimage") – where H = RIPEMD160(R) – from the recipient back to the sender.
- To ensure that the sender doesn't get cheated by the intermediaries, that intermediaries get reimbursed (and ideally compensated with fees) by the sender, and the recipient gets the payment.
Why a gossip protocol?
- To implement payment forwarding.
- So that a node A, of some channel A -> B, can listen to node_announcement and channel_announcement messages from other nodes (the network "gossip") to create a channel graph, i.e. its view of the network, from which it can find paths, e.g. A -> B -> C -> D, so that it can make payments to e.g. D without opening a channel to it.
Why Source routing?
- To give sender nodes full control over the route their payment follows through the network.
- So that senders can specify the total number of hops, total cumulative fee, and total worst-case time-lock period enforced by the HTLC.
Why Onion-routing / Sphinx-based mix network?
- To securely and privately route HTLCs, i.e. conditional payments, within the network.
- So that senders can encode the whole path as nested encrypted layers (like an onion) so that each intermediary ("hop") sees ("peels") only the layer that pertains to it ("hop payload"). I.e. Cryptographic packet routing.
- So that intermediaries, called "routing nodes" in Payment forwarding context, don't know who the original sender and final recipient are, and thus can't engage in things such as censorship. (Unlike e.g. Internet IP routing, where each hop can see the origin and recipient in the IPv4 packet.)
- 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.
Why Path finding by iterative trial-and-error?
- Because of incomplete (by design, see Onion-routing section) and ever-changing information, e.g. a channel's balances (how the capacity is allocated between the two peeers at a given moment) and liquidity (balances minus channel reserve and shit) are unknown to the network, for privacy reasons.
- Because the only channel information known to the rest of the network via channel gossip announcements is the aggregate capacity, for privacy and scalability (because broadcasting balance updates to the whole network would slow everything down again).
Why Commitment transactions?
- So that no one can cheat, because any participant can take their off-chain state (which is kept structured as a transaction) on-chain at any time.
- 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.
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.
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."
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.
Why the Noise Protocol Framework?
- For authentication, encryption, privacy, and resistance to traffic analysis, eavesdropping, and other malicious interference.
- To authenticate any information announced on behalf of a node, by using a long-term public key on Bitcoin's secp256k1 curve.

External Resources #

See current full book's WIP here.