<style> .reveal { font-size: 36px; } </style> # The Lightning Network --- ## About me - Materials Engineer - Self-taught programmer ( Python, C++, Rust, Bitcoin) - Lightning Engineer at Gotenna / Global Mesh Labs - Teacher at Qala ([qala.dev](qala.dev)) --- ## Survey --- ## What is Lightning? ---- Lightning _is_ bitcoin ---- ## Lightning vs. Bitcoin - Better sender privacy - Lower transaction fees - Instant settlement - Enables micropayments ---- ## How to use Lightning 1. Get a Lightning wallet 1. Send bitcoin to Lightning wallet 1. Open a channel (often automatic) 1. Send / recv transactions ---- <iframe width="1024" height="600" style="background: #FFFFFF;" data-src="https://jochen-hoenicke.de/queue/#BTC,24h,weight" data-preload></iframe> ---- <iframe width="600" height="600" style="background: #FFFFFF;" data-src="https://mempool.jhoenicke.de/lightning/" data-preload></iframe> --- ## Why not scale bitcoin? ---- ### Bitcoin scalability - Poor - Every node validates every transaction - Requires global consensus - Block size ~ 1.7MB - Time between blocks ~ 10 min - ~ 3 tx/second ---- ### Response to Bitcoin Satoshi: > I've been working on a new p2p electronic cash system... James Donald: > We very, very much need such a system, but the way I understand your proposal it does not seem to scale to the required size. ---- ### Scaling approaches - Reduce transaction size :x: - SegWit - Increase block size / speed up block time :x: - Only a linear increase - Affects decentralisation; bandwidth, CPU, disk space etc. ---- ### Scaling approaches - Segment network :heavy_check_mark: - Don't make everyone validate every transaction - Can maintain security & trustlessness - Aggregate many payments into fewer payments :heavy_check_mark: ---- ## Aggregating payments - Like a bar tab :beer: 1. Set up 2. Make (many) payments 3. Settle them all with a single transaction at the end ```mermaid flowchart LR S[set up tab] F[settle tab] subgraph P[make many payments] direction TB bar tx1 tx2 tx3 ... tx1 --> bar tx2 --> bar tx3 --> bar tx4 --> bar ... --> bar end S ---> P P ---> F ``` --- ## Payment Channels - Many bitcoin transactions can be aggregated into two: 1. Open the channel (set up tab) <span style="color:#98c379">... many payments can take place here, just don't broadcast them! ...</span> 2. Close the channel (settle tab) ---- ### How a simple payment channel operates ```mermaid flowchart LR Alice Bob Alice2[Alice] Open[channel open] Tx1[channel close v1] Tx2[channel close v2] Tx3[channel close v3] Tx4[channel close n] Close[channel close n] classDef onchain fill:orange,stroke:#333,stroke-width:3px; classDef offchain fill:green,stroke:#333,stroke-width:3px,color:white; class Open,Close onchain; class Tx1,Tx2,Tx3,Tx4 offchain; subgraph updates[ ] direction TB Tx1 -- Alice pays Bob 1\nAlice:4 Bob:1 --> Tx2 Tx2 -- Alice pays Bob 1\nAlice:3 Bob:2 --> Tx3 Tx3 -- Alice pays Bob 1\nAlice:2 Bob:3 --> Tx4 end Alice -- 5 --> Open Open --> updates updates --> Close Close -- 2 --> Alice2 Close -- 3 --> Bob ``` ---- ### Problems with these payment channels - Mono-directional - Need a direct channel with everyone you want to pay Only really useful for recurring payments with a single counterparty --- ## Lightning payment channels 1. Use <span style="color:#98c379">multisignature</span> bitcoin transactions to setup and update the channel 2. Use <span style="color:#98c379">revocable</span> transactions so that old versions can be made invalid 3. Allow <span style="color:#98c379">multi-hop</span> payments over multiple connected channels ---- ### How a Lightning channel operates ```mermaid flowchart LR Alice Bob Alice2 Bob2 Open[channel open] Tx1[channel close v1] Tx2[channel close v2] Tx3[channel close v3] Tx4[channel close n] Close[channel close n] classDef onchain fill:orange,stroke:#333,stroke-width:3px; classDef offchain fill:green,stroke:#333,stroke-width:3px,color:white; class Open,Close onchain; class Tx1,Tx2,Tx3,Tx4 offchain; subgraph updates[ ] direction TB Tx1 -- Alice pays Bob 4\nAlice:1 Bob:4 --> Tx2 Tx2 -- Bob pays Alice 3\nAlice:4: Bob:1 --> Tx3 Tx3 -- Alice pays Bob 1\nAlice:3 Bob:2 --> Tx4 end Alice -- 5 --> Open Bob -- 0 --> Open Open --> updates --> Close Close -- 3 --> Alice2 Close -- 2 --> Bob2 ``` ---- ### Multisignature - Transaction must be signed by both participants before valid - Stops spending the coins unilaterally ```mermaid flowchart LR Alice Bob MS[2-of-2 Multisig] MS1[...] Alice-- signed by Alice -->MS Bob-- signed by Bob -->MS MS-- signed by Alice + Bob -->MS1 ``` ---- ### Revocable transactions ```mermaid sequenceDiagram %%{init: { "sequence": { "wrap": true, "width":300, "height":30} } }%% Alice->>Bob: <br/>Sign new transaction Bob->>Alice: <br/>Revoke previous transaction (send secret) Bob->>Alice: <br/>Sign new transaction Alice->>Bob: <br/>Revoke previous transaction (send secret) ``` ---- ### Multi-hop channels If we had channels between Alice + Bob, Bob + Carol and Carol + Dave: ```mermaid flowchart LR Alice Bob Carol Dave Alice<--->Bob Bob<--->Carol Carol<--->Dave ``` We want Alice to be able to safely pay Dave without trusting anyone: ```mermaid flowchart LR Alice Bob Carol Dave Alice-. 0.25 .->Bob Bob-. 0.25 .->Carol Carol-. 0.25 .->Dave ``` This would greatly increase the number of people we could make payments to --- ## Lightning payments :zap: Lightning payments are exactly these revocable, multi-hop off-chain Bitcoin transactions :tada: - No need to make channels to everyone - Can send to anybody else in the network you can make a path to --- ## Lightning problems - Onboarding - Liquidity - Routing - Privacy - Trust - Liveness --- ### Onboarding - Need an on-chain transaction to both open and close a channel - If you can't get space for your tx in a block, risk being cheated! --- ## Liquidity - Like beads on an abacus - Can only send if there is sufficient liquidity in the right direction - Can limit transaction value <img src="https://miro.medium.com/max/1400/1*h3R-vZLFYugnghEF405QOg.gif"> source: https://medium.com/@peter_r/visualizing-htlcs-and-the-lightning-networks-dirty-little-secret-cb9b5773a0 ---- ### Liquidity ```mermaid flowchart LR id1((A)) --- id2(( )) --- id3(( )) --- id4(( )) --- id5(( )) --- id6(( )) --- id7(( )) --- id8(( )) --- id9(( )) --------------- id10((B)) ``` Liquidity all at `A` `A` can only send and `B` can only recieve ```mermaid flowchart LR id1((A)) --- id2(( )) --- id3(( )) --- id4(( )) --- id5(( )) ===============> id6(( )) --- id7(( )) --- id8(( )) --- id9(( )) --- id10((B)) ``` Balanced liquidity `A` and `B` can both send and receive ```mermaid flowchart LR id1((A)) ===============> id2(( )) --- id3(( )) --- id4(( )) --- id5(( )) --- id6(( )) --- id7(( )) --- id8(( )) --- id9(( )) --- id10((B)) ``` Liquidity at `A` depleted `A` can only recieve and `B` can only send ---- ### Re-balancing liquidity <img src="https://i.imgur.com/4YX2Sln.png"> source: https://www.peerswap.dev --- ### Routing - Computationally expensive - Can be outsourced --- ### Privacy - Reciever must share fixed pubkey and ip address - Could use Tor - Blinded paths - "Private channels" are not private - Balance probing --- ### Trust - Trust channel counterparty not to close the channel - Wastes *your* on-chain transaction fees --- ### Liveness - Must be online to receive - LSPs - Must monitor blockchain semi-regularly to avoid being cheated - Penalty mechanism sufficient deterrent? --- ## How to use Lightning 1. Get a Lightning wallet 1. Send bitcoin to Lightning wallet 1. Open a channel (often automatic) 1. Send / recv transactions ---- ### Lightning wallets (mobile/lite) | Name | Model | | ----------------- | ------------- | | Wallet of Satoshi | Custodial | | Blue Wallet | Custodial | | Phoenix | Non-custodial | | Muun | Non-custodial | | Breez | Non-custodial | | ... | | ---- ### Full lightning nodes | Name | Language | | --------------------- | ---------------------- | | Core-LN (C-Lightning) | C, Rust, (plugins any) | | LND | Go | | Electrum | Python | | Rust Lightning | Rust | | Eclair | Scala | All include wallet functionality ---- ### Testing Lightning on mainnet pollofeed.com <img src="https://i.imgur.com/lNLtYrm.png" height="400px"> #reckless --- ## Lightning summary - Scales bitcoin payments <span style="color:#98c379">trustlessly</span> - Compresses many off-chain transactions into two on-chain transactions - <span style="color:#98c379">Better privacy, lower fees, faster speed and smaller payment amounts</span> --- ### Thank you! :sheep: You can find me on - Twitter: [@willcl_ark](https://twitter.com/willcl_ark) - GitHub: [@willcl-ark](https://github.com/willcl-ark) --- ### Questions