The Lightning Network

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
2. Send bitcoin to Lightning wallet
3. Open a channel (often automatic)
4. Send / recv transactions

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
  • SegWit
• Increase block size / speed up block time
  • Only a linear increase
  • Affects decentralisation; bandwidth, CPU, disk space etc.

Scaling approaches

• Segment network
  • Don't make everyone validate every transaction
  • Can maintain security & trustlessness
• Aggregate many payments into fewer payments

Aggregating payments

• Like a bar tab
  1. Set up
  2. Make (many) payments
  3. Settle them all with a single transaction at the end

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
    

How a simple payment channel operates

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

How a Lightning channel operates

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

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

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:

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:

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

Liquidity

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

flowchart LR
    id1((A)) --- id2(( )) --- id3(( )) --- id4(( )) --- id5(( )) ===============> id6(( )) --- id7(( )) --- id8(( )) --- id9(( )) --- id10((B))

Balanced liquidity
A and B can both send and receive

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

source: https://www.peerswap.dev

Lightning wallets (mobile/lite)

Full lightning nodes

All include wallet functionality

Testing Lightning on mainnet

pollofeed.com

#reckless