Introduction to the Lightning Network
Protocol
Mainz
March 19th 2019
Disclaimer
After this talk you will hopefully understand this slide!
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
HTLC
HTLC
R
R
R
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
update_add_htlc
update_add_htlc
update_fullfil_htlc
update_fullfil_htlc
update_fullfil_htlc
Outline: Understand the Lightning Network
Chapter 0: Prologue
Chapter 0: Prologue
Why Lightning network?
3 Building blocks of the Lightning Network
Construction of Payment channels (RSMCs)
(Chapter 1)
Purpose of a trustless bidirectional payment channel
→ How can this technically be possible?
A comparison with HTTP
How does a HTTP server push work?
More details at: https://en.wikipedia.org/wiki/Push_technology
Payment channels are constructed by deferring the publication or broadcast of some TXs to the future
A payment channel is a 2-2 multisig Address together with some (smart?) contract
The secret smart contract (RSMC)
Funding Transaction
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Output x
(100 mBTC)
Alice's Key
Reference
ScriptPubKey:
OP_HASH160 <scriptHash> OP_EQUALVERIVY
Inside
U
N
P
U
B
L
I
S
H
E
D
Legend for colors:
Broadcasted and mined
Not boradcasted
Should be broadcasted
Should not be broadcasted
Cannot by minded
(Consumed outputs are already spent)
Funding Transaction
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Commitment Transaction 1
Input (100 mBTC)
Reference
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
Bob's Key
Output x
(100 mBTC)
Alice's Key
Reference
ScriptPubKey:
OP_HASH160 <scriptHash> OP_EQUALVERIVY
sigScript:
<sig1>... <serializedScript>
Script:
OP_2 <Alice><Bob> OP_2 OP_CHECKMULTISIG
Inside
Inside
U
N
P
U
B
L
I
S
H
E
D
U
N
P
U
B
L
I
S
H
E
D
Funding Transaction
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Commitment Transaction 1
Input (100 mBTC)
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
Bob's Key
Output x
(100 mBTC)
Alice's Key
Reference
ScriptPubKey:
OP_HASH160 <scriptHash> OP_EQUALVERIVY
sigScript:
<sig1>... <serializedScript>
Script:
OP_2 <Alice><Bob> OP_2 OP_CHECKMULTISIG
Inside
Inside
This Commitment Transaction (CTX1) encodes the balance sheet of the channel.
It can be broadcasted to the blockchain at any time
Funding Tx must use segWit outputs to prevent malleability
Reference
P
U
B
L
I
S
H
E
D
With CTX2 Bob updates the channel Balance
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Commitment Transaction 1
Input (100 mBTC)
Reference
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
Bob's Key
Commitment Transaction 2
Input (100 mBTC)
Reference
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
Bob's Key
potential
double �spending?
Bob effectively sends 10 mBTC
to Alice
Anybody seeing a problem with this?
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Commitment Transaction 1
Input (100 mBTC)
Reference
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
Bob's Key
Commitment Transaction 2
Input (100 mBTC)
Reference
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
Bob's Key
potential
double �spending?
Bob broadcasts CTX1 which is successfully mined
Bob just effectively stole 10 mBTC from Alice
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Commitment Transaction 1
Input (100 mBTC)
Reference
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
Bob's Key
Commitment Transaction 2
Input (100 mBTC)
Reference
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
Bob's Key
Goal: Make old CTXs somehow unpublishable
Funding Transaction
Input (100 mBTC)
Output 0
(100 mBTC)
Alice's & Bob's Key
Commitment Transaction 1
Input (100 mBTC)
Reference
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
Bob's Key
Commitment Transaction 2
Input (100 mBTC)
Reference
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
Bob's Key
We modify the output scripts of CTXs that it can be spent by either one of the two Transactions
Commitment Transaction 1b (Bob)
Input (100 mBTC)
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
RSMC
Reference
ScriptPubKey: (Output0)
OP_HASH160 <Alice's key> OP_EQUALVERIFY OP_CHECKSIG
Script: (Input Script to be able to spend Output1)
OP_IF
144 OP_CECKSEQUENCEVERIFY
OP_ DUP OP_HASH160 <Bob's key> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
2 <Alice R_1><Bob R_1> 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF
Revocable Delivery 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's & Alice's
Revocation Key #1
potential
double �spending?
Within 144 Blocks after CTX1b is mined only Alice can spend Output1 (if she has Bob's Revocation Key)
Commitment Transaction 1b (Bob)
Input (100 mBTC)
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
RSMC
Reference
ScriptPubKey: (Output0)
OP_HASH160 <Alice's key> OP_EQUALVERIFY OP_CHECKSIG
Script: (Input Script to be able to spend Output1)
OP_IF
144 OP_CECKSEQUENCEVERIFY
OP_HASH160 <Bob's key> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
2 <Alice R_1><Bob R_1> 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF
Revocable Delivery 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's & Alice's
Revocation Key #1
After 144 Blocks Bob can redeem his 10 mBTC & Alice can't spent BRTX1b without Bob's Key
Commitment Transaction 1b (Bob)
Input (100 mBTC)
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
RSMC
Reference
ScriptPubKey: (Output0)
OP_HASH160 <Alice's key> OP_EQUALVERIFY OP_CHECKSIG
Script: (Input Script to be able to spend Output1)
OP_IF
144 OP_CECKSEQUENCEVERIFY
OP_HASH160 <Bob's key> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
2 <Alice R_1><Bob R_1> 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF
Revocable Delivery 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's & Alice's
Revocation Key #1
A new Commitment Transaction is only signed if the other party reveals their previous revocation Key
Commitment Transaction 1b (Bob)
Input (100 mBTC)
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
RSMC
Reference
Revocable Delivery 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's & Alice's
Revocation Key #1
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Revocable Delivery 2b (Bob)
Input (20 mBTC)
Output 0 (20 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 2b (Bob)
Input (20 mBTC)
Output 0 (20 mBTC)
Bob's & Alice's
Revocation Key #2
Assume CTX1b is published and mined. Alice should immediately publish BRTX1b to punish Bob's breach
Commitment Transaction 1b (Bob)
Input (100 mBTC)
Output 0
(70 mBTC)
Alice's Key
Output 1
(30 mBTC)
RSMC
Reference
Revocable Delivery 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 1b (Bob)
Input (30 mBTC)
Output 0 (30 mBTC)
Bob's & Alice's
Revocation Key #1
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Revocable Delivery 2b (Bob)
Input (20 mBTC)
Output 0 (20 mBTC)
Bob's Key
Relative Time Lock (144)
Breach Remedy Tx 2b (Bob)
Input (20 mBTC)
Output 0 (20 mBTC)
Bob's & Alice's
Revocation Key #2
I
M
P
O
S
S
I
B
L
E
D
O
U
B
L
E
S
P
E
N
D
I
N
G
Some remarks on presented simplifications
Some remarks on dust outputs
Standard to_local witness script for commitment txs
Summary of what we have achieved now
Where is the (Lightning) Network of payment channels?
The Payment Process on the Lightning Network
(Chapter 2 / BOLT 11)
Comparing the payment process of on chain Bitcoin and off chain Lightning Network payments
What does it have to do with routing and the fact that lightning is a network?
Also look at: https://www.youtube.com/watch?v=Ol12GrAy8yk
Direct physical Payment with cash
How much?
Direct physical Payment with cash
10 $
How much?
Direct physical Payment with cash
10 $
Direct physical Payment with cash
10 $
Here is your receipt
Direct physical Payment with cash
Step two and three are atomic.
(At least ideally they should be atomic)
Here is your receipt
10 $
Direct on Chain Payment with Bitcoin
1 mBTC
Direct on Chain Payment with Bitcoin
1 mBTC
Look in Blockchain
Direct on Chain Payment with Bitcoin
Payment is still somewhat "atomic"
payee must have received the payment.
Payment can't be interrupted
1 mBTC
Look in Blockchain
Indirect physical payment with cash.
10 $
10 $
Here is your receipt
Here is your receipt
Indirect physical payment with cash.
10 $
10 $
Here is your receipt
Here is your receipt
Indirect physical payment with cash.
10 $
10 $
Here is your receipt
Here is your receipt
Indirect physical payment with cash.
10 $
I have no receipt yet!
Yeah 10$ for me (:
Indirect physical payment with cash.
I give you $10 IF you prove you have given $10 to payee
Indirect physical payment with cash.
I give you $10 IF you provide me with a receipt!
I give you $10 IF you prove you have given $10 to payee
Indirect physical payment with cash (+ service fee)
I give you $10 IF you provide me with a receipt!
I give you $10 IF you prove you have given $10 to payee
Indirect physical payment with cash (+ service fee)
10 $
Here is your receipt
Indirect physical payment with cash (+ service fee)
10 $
Here is your receipt
11 $
Here is the receipt
Huge risks in the physical world
→ Programmable smart contracts in Lightning (Hashed Time Locked Contracts)
10 $
Here is your receipt
11 $
Here is the receipt
Hashed time locked Contracts
Hashed time lock contracts in payment channels
BOLT 11 invoices - following the prefix b32 encoded
Invoices should be kept secret (privacy breaches)
Trustless routing of payments through a network of payment channels
(Chapter 3 / BOLT 03 )
Purpose of a trustless network of payment channels
→ How can this technically be possible?
A trusting (Lightning) Network of payment channels
Alice
0.35 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Carlie
0.3 BTC
channel B-C
0.35 BTC
0.5 BTC
0.15 BTC
0.3 BTC
A trusting (Lightning) Network of payment channels
Alice
0.35 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Carlie
0.3 BTC
channel B-C
0.35 BTC
0.5 BTC
0.15 BTC
0.3 BTC
send
0.1 BTC to Charlie
A trusting (Lightning) Network of payment channels
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.75 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Carlie
0.3 BTC
channel B-C
0.25 BTC
0.5 BTC
0.25 BTC
0.3 BTC
send
0.1 BTC to Charlie
A trusting (Lightning) Network of payment channels
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.75 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Carlie
0.3 BTC
channel B-C
0.25 BTC
0.5 BTC
0.25 BTC
0.3 BTC
send
0.1 BTC to Charlie
I am honest and forward the payment
A trusting (Lightning) Network of payment channels
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Carlie
0.4 BTC
channel B-C
0.25 BTC
0.4 BTC
0.25 BTC
0.4 BTC
send
0.1 BTC to Charlie
I am honest and forward the payment
Alice needed to trust Bob to forward the payment
Offered HTLC outputs
Offered HTLC outputs
Offered HTLC outputs
Received HTLC outputs for incomming HTLCs
HTLC-Timeout & HTLC Success Transactions
Key derivation (BOLT 03) for increased privacy
Some properties of the key derivation
A trustless (Lightning) Network of payment channels
Alice
0.35 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.3 BTC
channel B-C
0.35 BTC
0.5 BTC
0.15 BTC
0.3 BTC
send
0.1 BTC to Charlie
Some Hash H of R
A trustless (Lightning) Network of payment channels
Alice
0.35 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.3 BTC
channel B-C
0.35 BTC
0.5 BTC
0.15 BTC
0.3 BTC
send
0.1 BTC to Charlie
Some Hash H of R
Some Hash H of R
A trustless (Lightning) Network of payment channels
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.3 BTC
channel B-C
0.25 BTC
0.5 BTC
0.15 BTC
0.3 BTC
Some Hash H of R
H
0.1 BTC
I can't claim 0.1 BTC without knowing R (within some time)
If Bob doesn't provide R
I can soon claim back 0.1 BTC
A trustless (Lightning) Network of payment channels
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.55 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.3 BTC
channel B-C
0.25 BTC
0.4 BTC
0.15 BTC
0.3 BTC
Some Hash H of R
H
0.1 BTC
I can't claim 0.1 BTC without providing R (within some time)
I pay charly if she can provide R (within some shorter time)
H
0.1 BTC
A trustless (Lightning) Network of payment channels
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.3 BTC
channel B-C
0.25 BTC
0.5 BTC
0.15 BTC
0.3 BTC
Some Hash H of R
H
0.1 BTC
H
0.1 BTC
Tell Charlie R
R
Bob checks that R hashes to H
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.55 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.4 BTC
channel B-C
0.25 BTC
0.4 BTC
0.15 BTC
0.4 BTC
Some Hash H of R
H
0.1 BTC
R
I can only claim 0.1 BTC by providing R to Bob
R
If successfully check
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.55 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.4 BTC
channel B-C
0.25 BTC
0.4 BTC
0.15 BTC
0.4 BTC
Some Hash H of R
H
0.1 BTC
R
Great! Now I can also claim 0.1 BTC because I know R
R
Bob claims to settle htlc after releasing R
Alice
0.25 BTC
2-2 Multisignature Wallet
0.5 BTC
Bob
0.65 BTC
channel A-B
2-2 Multisignature Wallet
0.8 BTC
Charlie
0.4 BTC
channel B-C
0.25 BTC
0.4 BTC
0.25 BTC
0.4 BTC
Some Hash H of R
R
Bob must have payed Charlie otherwise he would not have known R.
I didn't need to trust him.
R
R
Source based Onion Routing - Sphinx Mix format
Setting up htlcs
(Chapter 4 / BOLT 04)
Why using the SPHINX mix Format?
Assuming enough capacity on all channels
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
Create onions starting from David (no payment hash)
Per_hop data includes the amount and route info
Per_hop payload for david (simplified!)
4:outgoing_cltv_value
8: amt_to_forward
8: short_channel_id
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
0
300
9
Onion for David (without HMAC and filler)
4:outgoing_cltv_value
8: amt_to_forward
8: short_channel_id
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
0
300
9
u3h4kj23048yerg2j3r
Ek D
Payload for Charlie (Simplified)
4:outgoing_cltv_value
8: amt_to_forward
8: short_channel_id
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Onion for Charly (without HMAC and filler)
4:outgoing_cltv_value
8: amt_to_forward
8: short_channel_id
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
Payload for Bob (simplified)
4:outgoing_cltv_value
8: amt_to_forward
8: short_channel_id
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
Onion for Bob without HMAC and filler
4:outgoing_cltv_value
8: amt_to_forward
8: short_channel_id
Alice
Bob
Carlie
David
Send 300 satoshis without direct payment channel
sid:
357
sid:
452
sid: 74
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g-
Ek B
Some notes on the presented simplifications
Transport Layer - The Noise Protocol Framework
(Chapter 5 / BOLT 08)
Communication is encrypted and authenticated
Lightning uses the Noise Protocol Framework
Lightning Network uses the Noise XK pattern
XK:
< -- s
…
--> e, es (act 1: send ephemeral key to responder)
<-- e, ee (act 2 send responders ephemeral key to sender)
--> s, se (act 3 authenticate sender)
Payload security properties achieved by XK
Identity hiding properties achieved by XK
Key setup for the Transport layer
Authenticated Key Agreement Handshake
Processing of handshake data
Handshake State
Noise protocol instantiation
Noise protocol setup: Act 1 --> e, es (50 bytes)
Send m =0 || e.pub.serialize() || c
Noise protocol setup: Act 1 --> e, es (50 bytes)
Send m =0 || e.pub.serialize() || c
Important! MAC check in decrypt. This allows us to know the authenticity of the ephemeral key e.
Remember senders e and receivers re are the same
Send m =0 || e.pub.serialize() || c
Important! MAC check in decrypt. This allows us to know the authenticity of the ephemeral key e.
That is exactly the DH-Key exchange
Send m =0 || e.pub.serialize() || c
Important! MAC check in decrypt. This allows us to know the authenticity of the ephemeral key e.
Noise protocol setup: Act 2 <-- e, ee (50 bytes)
Send m =0 || e.pub.serialize() || c
Noise protocol setup: Act 2 <-- e, ee (50 bytes)
Send m =0 || e.pub.serialize() || c
Important! MAC check in decrypt. This allows us to know the authenticity of the ephemeral key of the responder e.
Pay attention to the notation of e, re and ee
Send m =0 || e.pub.serialize() || c
Important! MAC check in decrypt. This allows us to know the authenticity of the ephemeral key of the responder e.
Noise protocol setup: Act 3 --> s, se (66 bytes)
Send m =0 || c || t
Noise protocol setup: Act 3 --> s, se (66 bytes)
Send m =0 || c || t
Encrypting Messages
Decrypting Messages
Lightning Message Key Rotation
Messaging / Peer Protocol
(Chapter 6 / BOLT 01 / BOLT 02)
Purpose of the Peer Protocol
Format of Lightning messages
The init message
The error message
The ping and pong messages
Establishing a channel
(Chapter 6a / BOLT 02)
Establishing a channel
The open_channel message (type 32) ---->
The accept_channel message (type 33) <----
The funding_created message (type 34) ---->
The funding_signed message <----
On Transaction Malleability and the need for segWit
The funding_locked message (type 36) ----> <----
Closing a channel
(Chapter 6b / BOLT 02 / BOLT 05)
3 ways for closing a channel (BOLT 05)
The good way - Mutual Close (always preferable)
The shutdown message
The closing_signed message
The bad way - Unilateral / Force Close
The ugly way - Revoked Transaction Close
Normal operation of a channel
(Chapter 6c / BOLT 02)
3 messages are necessary to operate a channel
(Chapter 7c / BOLT 02)
The 5 stages for a htlc to become valid
Alice wants to offer a payment to Bob of 15 mBTC
The 5 stages for a htlc to become valid
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 3b (Bob)
Input (100 mBTC)
Output 0
(65 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
unsigned
2. Alice sends a commitment_signed message to Bob
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 3b (Bob)
Input (100 mBTC)
Output 0
(65 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
3. Bob sends a revoke_and_ack message to Alice
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 3b (Bob)
Input (100 mBTC)
Output 0
(65 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
Commitment Transaction 3a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(65 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
unsigned
revoked
4. Bob sends a commitment_signed message to Alice
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 3b (Bob)
Input (100 mBTC)
Output 0
(65 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
Commitment Transaction 3a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(65 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
revoked
5. Alice sends a revoke_and_ack message to Bob
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 3b (Bob)
Input (100 mBTC)
Output 0
(65 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
Commitment Transaction 3a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(65 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
revoked
Only now Bob SHOULD forward the htlc!
Commitment Transaction 2b (Bob)
Input (100 mBTC)
Output 0
(80 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Commitment Transaction 2a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(80 mBTC)
RSMC
Commitment Transaction 3b (Bob)
Input (100 mBTC)
Output 0
(65 mBTC)
Alice's Key
Output 1
(20 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
Commitment Transaction 3a (Alice)
Input (100 mBTC)
Output 0
(20 mBTC)
Bob's Key
Output 1
(65 mBTC)
RSMC
Output 2
(15 mBTC)
HTLC
revoked
The update_add_htlc offers a htlc to another node
The commitment_signed message
The revoke_and_ack message
4 reasons for removing an htlc
The update_fullfil_htlc message
The update_fail_htlc message
The update_fail_malformed_htlc
Rational for Retransmission messages
Workflow of a Payment starts with a BOLT 11 invoice
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
Alice
David
After receiving the invoice Alice selects a path to David
Alice
Bob
Charlie
David
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
Alice
David
Find a path (for example via Bob and Charlie)
Alice creates the Onion package (starting from David)
Alice
Bob
Charlie
David
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
Alice offers the first htlc to Bob
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
Bob processes the onion and offers an htlc to Charlie
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
HTLC
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
update_add_htlc
Charlie processes the onion and offers htlc to David
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
HTLC
HTLC
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
update_add_htlc
update_add_htlc
David checks the amount an releases the preimage
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
HTLC
HTLC
R
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
update_add_htlc
update_add_htlc
update_fullfil_htlc
Upon receipt of preimage charly claims funds from Bob
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
HTLC
HTLC
R
R
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
update_add_htlc
update_add_htlc
update_fullfil_htlc
update_fullfil_htlc
Workflow of a Payment on the Lightning Network
Alice
Bob
Charlie
David
HTLC
Payment Hash
R → H(R)
Bolt 11 Invoice
H(R)
HTLC
HTLC
R
R
R
Alice
David
Find a path (for example via Bob and Charlie)
0
300
9
u3h4kj23048yerg2j3r
Ek D
452
300
18
Ek C
aksjhdflka813r83n09aw0923kjqk34jt2kjt3jhk2jh3tqkjw
74
301
41
374yiu3h4ot8h2no2iht2htp82hts98dfgoh2408h2048gh2084ghh2g0240gh24hg082h4g
Ek B
Alice creates Onion package
update_add_htlc
update_add_htlc
update_add_htlc
update_fullfil_htlc
update_fullfil_htlc
update_fullfil_htlc
What can be seen by channel closes on chain?
The Gossip Protocol
(Chapter 7 / BOLT 07)
Purpose of the Gossip Protocol
4 announcement messages
The announcement_signatures message
The channel_announcement message
The channel_announcment message format
The node_announcement message
The channel_update message
Deleting channels from the network view
Querying the gossip protocol for information
Advanced Topics
(Chapter 8)
Future enhancements to the BOLTs
(Chapter 8a)
Some advanced topics to talk about
Rendezvous Routing
AMP - Routing (Atomic Multipath Routing)
JIT - Routing (Just in Time Routing)
Dual funded channels
Splicing in & Splicing out funds
Eltoo channels
Multiparty channels / channel factories
Autopilots - Recommendation engines for channels
Watchtower solutions
Scriptless Scripts / 2 party ECDSA
Schnorr Signatures / MuSig
Chross chain atomic swaps / American Call options
Possible DoS Attack Vectors & spamming attacks
Privacy Considerations
(Chapter 8b)
The Lightning Network as spying tool?
Demonstrating private Channels
Sh
Transaction related to a Lightning network channel?
Tx-hash: 1d5b....e432
Spent by
Spent by
Tx-hash: 1d5b....e432
Spent by
Tx-hash: 1d5b....e432
Lightning node on chain wallets
Channel probing attack for channel balance
The Lightning Network a tool to increase privacy?
Security breaches by poor implementations
(Chapter 8c)
Implementations can (deliberately) compromise privacy
Not randomizing CLTV deltas in route construction
Implementations avoiding random overpayments
Man in the middle attacks of the Noise protocol
Bolt 02 bolt 03 basepoints unpredictable commitment tx
The various _basepoint fields are used to derive unique keys as described in BOLT #3 for each commitment transaction. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable to an external observer, even if one commitment transaction is seen; this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.
Possible infringement:
Don't follow the spec for key derivation (will not be detected)
Ephemeral keys on the Transport layer
Possible infringement:
Dual funded channels used to probe for offchain balance
Security breaches by services
(Chapter 8d)
3rd party services for lightning can compromise privacy
Lightning explorers like 1ml.com
Custodial services with KYC are an obvious risk
Decentralized Exchanges
Implementations (wallets) / plugins
User Interfaces / UX improving tools
References and helpful links
Backup Slides
A standard Bitcoin Transaction has 6 data fields
( The following is a brief summary of https://en.bitcoin.it/wiki/Transaction#Input )
(
Bitcoin Transaction with 3 inputs and 2 outputs
Data consists mainly of executable scripts!
A chain of Bitcoin Transactions with 2 UTXO
Spending a Pay-to-PubkeyHash (standard TX)
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
A video dissecting a P2PKH transaction: https://www.youtube.com/watch?v=1n4g3eYX1UI
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
Data is pushed on the stack
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
Data is pushed on the stack again
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
<pubKey>
The OP_CODE OP_DUP is being executed by pushing the top element to the stack again
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
The OP_CODE OP_HASH160 is being executed:
It takes the top element of the Stack
<pubKey>
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
<pubKeyHash>
The OP_CODE OP_HASH160 is being executed:
It takes the top element of the Stack
The RIPEMD-160 Hash is calculated
By design of the input and output script this will be the Hash of the Public Key (aka the Bitcoin Address)
<pubKey>
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
<pubKeyHash>
The OP_CODE OP_HASH160 is being executed:
It takes the top element of the Stack
The RIPEMD-160 Hash is calculated
And the result is pushed back on the stack
By design of the input and output script this will be the Hash of the Public Key (aka the Bitcoin Address)
<pubKey>
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
<pubKeyHash>
<pubKeyHash>
Data is pushed on the stack again
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<sig>
<pubKey>
OP_EQUALVERIFY checks if the two top elements of the stack are equal.
While checking the elements will be removed
Like the instruction set in the ALU of the CPU OP_CODES know how much data they need to consume (and will do so or fail otherwise)
<pubKeyHash>
<pubKeyHash>
Execution of Pay-to-PubkeyHash Script
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<True>
OP_CHECKSIG evaluates that the PubKey which was the top element fits to the signature which was the 2. Element on the stack
If this fits together ownership is proven and the Transaction will be added to the block with a new Output script.
After being mined the transaction is now considered to be spent. Double spending cannot take place since the assumption was that the output was not spent yet.
<sig>
<pubKey>
The Bitcoin miners will build the next block
Let's talk lightning!
I love taking photographs of lightning bolts...
Copyright notice
Thanks to Marietheres Viehler (aka journalspiration) for the design of the title slide.
About this slide deck
The purpose is to help spreading education about the Lightning Network Protocol so that the technology will be adopted more quickly by more people. This shall be my contribution to the Bitcoin / Lightning Network Community.
This slide deck - to the best of my knowledge - is the most comprehensive work making an introduction to the BOLT standard. I will hold several talks about this slide deck in Juni 2019 at the Bitcoin / Lightning Residency organized by Chaincodelabs who will also record the talk. So watch out for them because actual presentations of the slide deck will probably be more valuable than just the slides you're holding in your hand.
The slides are part of my effort to create a book about the lightning network. You can follow that effort at: https://github.com/renepickhardt/The-Lightning-Network-Book or you can support the effort at my fundrasing pages at: https://tallyco.in/s/lnbook or at: https://www.patreon.com/renepickhardt or at 1GZx8tWgDd21Rd8b1QdMrzdZGHgyfVkzaD part of this effort also consists of creating video tutorials and teaching materials on my Youtube Channel over at: https://www.youtube.com/user/RenePickhardt
This work was funded (sorted by amount of contribution from top to bottom) by: Me personally, fulmo.org, everyone who contributed to the above mentioned fundraiser and George Danzer.
Thank you to the lightning Developers and people in various telegram groups for helpful discussions