Lightning Network

Joseph Poon [email protected]

Thaddeus Dryja [email protected]

SF Bitcoin Devs http://lightning.network/

Feb 23, 2015
Problems
● Transactions aren’t instant
● Micropayments don’t actually work
○ High transaction fees
● “Bitcoin Doesn’t Scale”
“Bitcoin Doesn’t Scale”
● 1 MB blocks:
○ 7 transactions per second @ 250 bytes/tx
○ ~220 million transactions per year
○ Not enough for a city, let alone the world
● 1 Billion transactions per day:
○ 1.6 GB blocks (1655 MB)
○ 87 Terabytes/year (87029089 MB)
○ Maybe enough for one large metro area?
○ Centralization (mining!)
“Bitcoin Doesn’t Scale”
● 7 billion people doing 2 blockchain
transactions per day
○ 24 GB blocks
○ 3.5 TB/day
○ 1.27 PB/year
● Bigger blocks = Centralization
○ Very few full nodes
○ Very few miners
○ De facto inability to validate blockchain
Scalability Solutions
● The SQL Database Model
○ Very scalable, very fast
○ Off chain transactions implemented today with
ChangeTip, Coinbase, others
● Sidechains
○ Many blockchains with inter-chain transfers
● Payment Channels
○ Many payments between two pre-determined parties
Scalability Solutions
● The SQL Database Model
○ Also implemented by MTGox Redeemable Codes
● Sidechains
○ Not primarily a scalability solution
○ Sending funds between chains is two transactions
● Payment Channels
○ Only helps when people pay each other many times
(recurring billing, time-based microtransactions)
Anyone to Anyone Payments
● In bitcoin, any output can pay to any other
● In the SQL database model:
○ I need to have an entry in your SQL db
● On Sidechains:
○ I need to be on your sidechain
● In a Payment Channel:
○ I need to have a channel open with you
Bitcoin Lightning Network
● Payment channels between many parties in
a multi-hop hub and spoke model (similar to
internet routing)
● Minimally trusted intermediaries (they can’t
take your coins)
● With a malleability fix via a soft-fork, Bitcoin
can scale to billions of transactions per day
What are Payment Channels
● Introduced a while ago (not a new idea)
● Uses multi-sig
● Allows two people to send transactions to
each other without hitting the Bitcoin
blockchain
Unidirectional Channel
Alice and Bob Multisig
Alice
Channel
1 BTC
1 BTC

Alice Refund Signed by Bob

Address
30-day nLockTime
1 BTC
Unidirectional Channel
Alice
Alice and Bob Multisig
Alice No nLockTime
Channel 0.9 BTC
Signed by Alice
1 BTC
1 BTC
Bob

0.1 BTC

Alice Refund Signed by Bob

Address
30-day nLockTime
1 BTC
Unidirectional Channel
Alice
Alice and Bob Multisig
Alice No nLockTime
Channel 0.8 BTC
Signed by Alice
1 BTC
1 BTC
Bob

0.2 BTC
Alice

Alice Refund Signed by Bob No nLockTime 0.9 BTC

Address Signed by Alice
30-day nLockTime Bob
1 BTC

0.1 BTC
Unidirectional Channel
Alice
Alice and Bob Multisig
Alice No nLockTime
Channel 0.8 BTC
1 BTC
1 BTC
Bob

0.2 BTC
Alice

Alice Refund Signed by Bob No nLockTime 0.9 BTC

Address Signed by Alice
30-day nLockTime Bob
1 BTC

0.1 BTC
Bidirectional Channel
Alice and Bob Multisig
Alice
Channel
1 BTC
1 BTC

Alice Refund Signed by Bob

Address
30-day nLockTime
1 BTC
Bidirectional Channel - Payment
Alice
Alice and Bob Multisig 29-day
Alice nLockTime
Channel 0.9 BTC
Signed by Alice
1 BTC
1 BTC
Bob

0.1 BTC

Alice Refund Signed by Bob

Address
30-day nLockTime
1 BTC
Bidirectional Channel - Payment
Alice
Alice and Bob Multisig 29-day
Alice nLockTime
Channel 0.8 BTC
Signed by Alice
1 BTC
1 BTC
Bob

0.2 BTC
Alice
29-day
Alice Refund Signed by Bob nLockTime 0.9 BTC
Address Signed by Alice
30-day nLockTime Bob
1 BTC

0.1 BTC
Reversing Direction
Alice
Alice and Bob Multisig 28-day
Alice nLockTime
Channel 0.9 BTC
Signed by Bob
1 BTC
1 BTC
Bob

0.1 BTC
Alice
29-day
Alice Refund Signed by Bob nLockTime 0.8 BTC
Address Signed by Alice
30-day nLockTime Bob
1 BTC

0.2 BTC
Closing Bidirectional Channel
Alice

0.9 BTC
Alice and Bob Multisig
Alice Bob
Channel
1 BTC 0.1 BTC
1 BTC Alice
28-day
nLockTime 0.9 BTC
Signed by Bob
Bob

Alice Refund Signed by Bob 0.1 BTC

Address
29-day Alice
30-day nLockTime nLockTime
1 BTC
Signed by Alice 0.8 BTC
Bob

0.2 BTC
3 Party Payments

Bob

n el Ex
an ist
Ch ing
Ch
ing an
xist ne
E l

Alice Carol

Alice wants to pay Carol, they both have a channel open with Bob
3 Party Payments

o b Bob
B
to
BTC
. 0 1
0

Alice Carol
3 Party Payments

b Bob 0.0
B o 1
to BT
T C C
B to
0 1 Ca
0 . ro
l

Alice Carol
3 Party Payments - Trust Issues

o b Bob
B
to
BTC
. 0 1
0

Alice Carol
3 Party Payments - Trust Issues
“0.01 BTC to… I
b Bob think I’ll keep this.”
B o
to
BTC
. 0 1
0

Alice Carol

Problem: Bob can simply keep the 0.01 BTC

Problem: Carol can claim she never got the coins!
Hash-Locked Contracts
● Using one-way hash functions, Alice can
prove she sent funds to Carol off-chain
● Pay to Contract
○ Knowledge of secret R hashed into hash H proves
receipt
○ Receiver signs a contract stating if R is disclosed
funds have been received
Hash-Locked Contracts
Carol makes a random
number R, and keeps it secret.
Bob She computes the hash of R, hash
(R) = H

R
Hash
Alice function Carol

H
Hash-Locked Contracts
Carol sends H to Alice (via secure
Bob non-blockchain communication)

Alice Carol

H H R
Hash-Locked Contracts
Alice sends 0.01 BTC to a new
H output: Bob & hash160(H)
Bob
& To spend it, Bob needs to know R
o b
B
to
C
BT H
.01
0

Alice Carol

H H R
Hash-Locked Contracts
0.
H Bob 01
& BT
o b C
B to
to Ca
BTC H ro
l&
.01 H
0

Alice Carol
Bob sends 1 BTC to Carol & H
H H R
Hash-Locked Contracts
Ca
rol
H Bob ’s
& sig
o b na
B tur
to ea
C nd
BT H R R
.01
0

Alice Carol
Carol redeems Bob’s transfer, revealing R

H H R
Hash-Locked Contracts
Ca
R rol
d Bob ’s
sig
an na
e
ur tur
at ea
ign nd
b ’s s H R R
B o

Alice Bob now knows R and can Carol

spend Alice’s transfer.
The coins have gone from Alice
H R to Carol via Bob H R
 Problem!
● If Carol refuses to disclose R, she will hold
up the channel between Alice and Bob
○ If her channel expires after Alice and Bob’s she can
steal funds by redeeming the hashlock!
● Bob has to be rich for this to really work
3rd party low-trust multisig and/or extremely
small values sent can mostly work today
We Need to Create Complex
Contracts & Fix Malleability
● Trustless is better!
○ Corruptible custodians are undesirable
● Complex chained transactions don’t work
○ Malleability hostage scenarios
■ With chained multisig transactions, cannot be
mitgitated using existing BIPs
○ Two parties cannot spend from a multisig output
without being able to fund the parent transaction
Fixing Malleability & Contracts
● New sighash flags soft-fork:
○ SIGHASH_NORMALIZED
○ SIGHASH_NOINPUT
○ Allows you to build transaction without either party
able to broadcast the parent on the blockchain
More Info: http://youtu.be/jyDE-aFqJTs
Transaction Malleability: Threats and Solutions
Hashed Time-Lock Contract
1. If Bob can produce to Alice input R from
hash H within 3 days, Alice will pay Bob 0.01
BTC
2. The above clause is void after 3 days
3. Either party may agree to settle terms using
other methods if both agree
4. Violation of terms incurs a maximum penalty
of funds in this contract
Hashed Time-Lock Contract
Alice and Bob create new outputs and
HTLC Output transactions from their channel (off-chain)
0.01 BTC

k T ime 3-d
ay
Loc R nLo
0-n uires ckT
req ime

Bob Alice
(Payment) (Refund)

OP_DEPTH 3 OP_EQUAL OP_IF OP_HASH160 <R> OP_EQUALVERIFY OP_0 2

<AlicePubkey1> <BobPubkey1> 2 OP_CHECKMULTISIG OP_ELSE OP_0 2
<AlicePubkey2> <BobPubkey2> 2 OP_CHECKMULTISIG OP_END
Bitcoin Lightning Network
Alice wants to send funds to Dave via Bob and Carol

Bob Carol

Alice Dave
Bitcoin Lightning Network
Dave sends Alice hash H produced from random data R

Bob Carol

Alice Dave

H H R
Bitcoin Lightning Network

Bob Carol
im ay
kT -d
e
oc 3
nL TLC

H
H

Alice & Bob create an HTLC output in the payment

Alice channel to pay Bob 0.01 BTC, with a 3-day Dave
nLockTime refund back to Alice

H H R
Bitcoin Lightning Network
HTLC 2-day
nLockTime

Bob Carol
im ay
kT -d
e
oc 3
nL TLC

H H
H

Bob & Carol create an HTLC output in the payment

Alice channel to pay Carol 0.01 BTC, with a 2-day Dave
nLockTime refund back to Bob

H H R
Bitcoin Lightning Network
HTLC 2-day
nLockTime

HT Loc
Bob Carol

n
LC kTi
im ay
kT -d

1- me
e
oc 3

da
nL TLC

H H

y
H

Carol & Dave create an HTLC output in the payment

Alice channel to pay Dave 0.01 BTC, with a 1-day Dave
nLockTime refund back to Carol

H Dave can now get 0.01 BTC if she discloses R to

Carol H R
Bitcoin Lightning Network
HTLC 2-day
nLockTime

Bob Carol
im ay

0.
kT -d

01
e
oc 3
nL TLC

H H R

BT
C
H

Dave discloses R to Carol within 1 day. Carol now

Alice has enough information to pull funds from Bob. Dave
Carol and Dave agree to update the balances in the

H channel instead of broadcasting on the blockchain

H R
Bitcoin Lightning Network
0.01 BTC

Bob Carol
im ay

0.
kT -d

01
e
oc 3
nL TLC

H R H R

BT
C
H

Carol discloses R to Bob within 2 days. Bob now has

Alice enough information to pull funds from Alice. Dave
Bob and Carol agree to update the balances in the

H channel instead of broadcasting on the blockchain

H R
Bitcoin Lightning Network
0.01 BTC

Bob Carol

0.
01
C
BT

H R H R

BT
01

C
0.

Bob discloses R to Alice within 3 days. Alice can

Alice prove she sent funds to Dave. Dave
Alice and Bob agree to update the balances in the

H R channel instead of broadcasting on the blockchain

H R
Broken H R
Channel Blockchain

0.01 BTC

Bob Carol
im ay

0.
kT -d

01
e
oc 3
nL TLC

H H R

BT
C
H

If Bob and Carol don’t cooperate, Carol immediately

Alice closes out the channel and broadcasts all pending Dave
transactions in the channel onto the blockchain.

H Carol redeems the 0.01 by disclosing the HTLC

output and R on the Bitcoin blockchain. H R
Broken H R
Channel Blockchain

0.01 BTC

Bob Carol

0.
01
C
BT

H R H R

BT
01

C
0.

Bob observes R from the blockchain and can pull

Alice money from Alice off-chain. Dave

H R H R
Timeout
HTLC 2-day
nLockTime

HT Loc
Bob Carol

n
LC kTi
im ay
kT -d

1- me
e
oc 3

da
nL TLC

H H

y
H

If R never gets disclosed, timeouts occur sequentially

Alice from the destination. Dave
This decrementing timeout ensures that everyone

H can receive funds contingent upon it being sent

H R
Timeout
HTLC 2-day
nLockTime

Bob Carol
im ay
kT -d
e
oc 3
nL TLC

H H
H

If R never gets disclosed, timeouts occur sequentially

Alice from the destination. Dave
This decrementing timeout ensures that everyone

H can receive funds contingent upon it being sent

H R
Timeout

Bob Carol
im ay
kT -d
e
oc 3
nL TLC

H H
H

If R never gets disclosed, timeouts occur sequentially

Alice from the destination. Dave
This decrementing timeout ensures that everyone

H can receive funds contingent upon it being sent

H R
Timeout

Bob Carol

H H

The HTLC has now timed out for all channels and
Alice every party has updated their channel without the Dave
HTLC.

H If one party is uncooperative, that channel is

broadcast on the blockchain. H R
Implications
● Blockchain transactions can be circuits instead of
packets
○ Only uncooperative channels get broadcast early on
the blockchain
○ Nearly all transactions occur off-chain securely with
near-zero custodial default risk
○ Creating new channels are infrequent
● Relative OP_CHECKLOCKTIMEVERIFY
● Instant Transactions, Scalable Micropayments
Bitcoin Can Scale
● 7 billion people making 2 blockchain
transactions per day
○ 24 GB blocks (~2,400 MB)
■ 7e9 * 2txs * 250Bytes / 144 block/day
○ ~50 Mbit/s best-case with IBLT @ 2tx/day/person
● 7 billion people roll-over 2 channels per year
○ 133 MB blocks - unlimited transactions count
■ 7e9 * 2 txs * 500Byte / 52560blocks/yr
○ ~3 Mbit/s with IBLT
Bitcoin Can Scale
● 7 billion people making 20 blockchain
transactions per day
○ 240 GB blocks (~24,000 MB)
■ 7e9 * 20txs * 250Bytes / 144 block/day
○ ~500 Mbit/s best-case with IBLT @ 20tx/day/person
● 7 billion people roll-over 2 channels per year
○ 133 MB blocks - unlimited transactions count
■ 7e9 * 2 txs * 500Byte / 52560blocks/yr
○ ~3 Mbit/s with IBLT
Bitcoin Can Scale
● Full Blockchain Archive
○ 7 TB/year (7,000 GB) /w ~unlimited transactions
○ $300/year blockchain archival storage (2015 prices)
● Blockchain Pruning
○ Server nodes and miners only keeping recent blocks
and UTXOs have enough storage today (2 TB,
common in current-gen desktops)
● Mobile Wallets (Lightweight SPV clients)
○ Several megabytes of storage