Lightning Network Slide

7/26/2019 Lightning Network Slide

1/54

Lightning Network

Joseph Poon [email protected] Dryja [email protected]

http://liSF Bitcoin DevsFeb 23, 2015


2/54

Problems

Transactions arent instant Micropayments dont actually work

High transaction fees

Bitcoin Doesnt Scale


3/54


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!)


4/54


7 billion people doing 2 blockchaintransactions 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


5/54

Scalability Solutions

The SQL Database Model Very scalable, very fast

Off chain transactions implemented today w

ChangeTip, Coinbase, others

Sidechains Many blockchains with inter-chain transfers

Payment Channels Many payments between two pre-determine


6/54

Scalability Solutions

The SQL Database Model Also implemented by MTGox Redeemable C

Sidechains Not primarily a scalability solution

Sending funds between chains is two transa Payment Channels

Only helps when people pay each other ma

(recurring billing, time-based microtransacti


7/54

Anyone to Anyone Payments

In bitcoin, any output can pay to any o 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


8/54

Bitcoin Lightning Network

Payment channels between many para multi-hop hub and spoke model (siminternet routing)

Minimally trusted intermediaries (theytake your coins)

With a malleability fix via a soft-fork, Bcan scale to billions of transactions pe


9/54

What are Payment Channels

Introduced a while ago (not a new ide Uses multi-sig Allows two people to send transaction

each other without hitting the Bitcoinblockchain


10/54

Unidirectional Channel

Alice

1 BTC

Alice and Bob MultisigChannel

1 BTC

Alice RefundAddress

1 BTC30-day nLockTime

Signed by Bob


11/54


Alice

1 BTC


1 BTC

Alice RefundAddress


No nLockTime

Signed by Alice

Signed by Bob


12/54


Alice

1 BTC


1 BTC

Alice RefundAddress


No nLockTime

No nLockTime

Signed by Alice

Signed by Alice

Signed by Bob


13/54


Alice

1 BTC


1 BTC

Alice RefundAddress


No nLockTime

No nLockTime

Signed by Alice

Signed by Bob


14/54

Bidirectional Channel

Alice

1 BTC


1 BTC

Alice RefundAddress


Signed by Bob


15/54

Bidirectional Channel - Paymen

Alice

1 BTC


1 BTC

Alice RefundAddress


29-daynLockTime

Signed by Alice

Signed by Bob


16/54

Bidirectional Channel - Paymen

Alice

1 BTC


1 BTC

Alice RefundAddress


Signed by Bob

29-daynLockTime

Signed by Alice

29-daynLockTime

Signed by Alice


17/54

Reversing Direction

Alice

1 BTC


1 BTC

Alice RefundAddress


Signed by Bob

28-daynLockTime

Signed by Bob

29-daynLockTime

Signed by Alice


18/54

Closing Bidirectional Channel

Alice

1 BTC


1 BTC

Alice RefundAddress


Signed by Bob

28-daynLockTime

Signed by Bob

29-daynLockTime

Signed by Alice

Alice

0.9 BTCBob

0.1 BTC


19/54

3 Party Payments

Alice

Bob

Existing

Cha

nnel ExistingChannel

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


20/54

3 Party Payments

Alice

Bob

0.01B

TCto

Bob


21/54

3 Party Payments

Alice

Bob

0.01B

TCto

Bob

0.01BTCtoC


22/54

3 Party Payments - Trust Issues

Alice

Bob

0.01B

TCto

Bob


23/54

Alice

Bob

0.01B

TCto

Bob

0.01 BTC to I

think Ill keep this.

Problem: Bob can simply keep the 0.01 BTC

Problem: Carol can claim she never got the coins!

3 Party Payments - Trust Issues


24/54

Hash-Locked Contracts

Using one-way hash functions, Alice cprove she sent funds to Carol off-chai

Pay to Contract Knowledge of secret R hashed into hash H

receipt Receiver signs a contract stating if R is disc

funds have been received


25/54


Alice

Bob

R

H

Hashfunction

Carol makes a randonumber R, and keep

She computes the h(R) = H


26/54


Alice

Bob

HH

Carol sends H to Al

non-blockchain com


27/54


Alice

Bob

HH

H

Alice sends 0.01 BT

output: Bob & hash1To spend it, Bob ne

0.01

BTC

toBob

&H


28/54


Alice

Bob

HH

H0.01

BTC

toBob

&H

Bob sends 1 BTC to Carol & H

0.01BTCtoCarol


29/54


Alice

Bob

HH

H0.01

BTC

toBob

&H

Carol redeems Bobs transfer, revealing R

R

Carolssignaturean


30/54


Alice

Bob

HH

H R

Carolssignaturean

Bob now knows R and canspend Alices transfer.The coins have gone from Alice

to Carol via BobR

Bobs

sign

atur

eandR


31/54

Problem!

If Carol refuses to disclose R, she willup the channel between Alice and Bo If her channel expires after Alice and Bobs

steal funds by redeeming the hashlock!

Bob has to be rich for this to really wo3rd party low-trust multisig and/or extremsmall values sent can mostly work today

We Need to Create Complex


32/54

We Need to Create Complex

Contracts & Fix Malleability

Trustless is better! Corruptible custodians are undesirable Complex chained transactions dont w

Malleability hostage scenarios

With chained multisig transactions, cannmitgitated using existing BIPs

Two parties cannot spend from a multisig o

without being able to fund the parent transa


33/54

Fixing Malleability & Contracts

New sighash flags soft-fork: SIGHASH_NORMALIZED SIGHASH_NOINPUT

Allows you to build transaction without eithe

able to broadcast the parent on the blockchMore Info: http://youtu.be/jyDE-aFqJTs

Transaction Malleability: Threats and Solutions
http://youtu.be/jyDE-aFqJTs


34/54

Hashed Time-Lock Contract

1. If Bob can produce to Alice input R frohash H within 3 days, Alice will pay BoBTC

2. The above clause is void after 3 days

3. Either party may agree to settle termsother methods if both agree

4. Violation of terms incurs a maximum p

of funds in this contract


35/54

Hashed Time-Lock Contract

OP_DEPTH 3 OP_EQUAL OP_IF OP_HASH160 OP_EQUALVERIFY OP_0 2 2 OP_CHECKMULTISIGOP_ELSE OP_0 2 2 OP_CHECKMULTISIGOP_END

HTLC Output

0.01 BTC

Bob(Payment) Alice(Refund)

0-nLoc

kTime

require

sR

3-daynLockTime

Alice and Bob create new transactions from their cha


36/54

Bitcoin Lightning NetworkAlice wants to send funds to Dave via Bob and Carol

Alice

Bob Carol


37/54


Alice

Bob Carol

Dave sends Alice hash H produced from random data R

HH


38/54


Alice

Bob Carol

Alice & Bob create an HTLC output in the paymentchannel to pay Bob 0.01 BTC, with a 3-daynLockTime refund back to Alice

HH

HTLC

3-day

nLockT

ime

H


39/54


Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

HTLC 2-day

nLockTime

Bob & Carol create an HTLC output in the paymentchannel to pay Carol 0.01 BTC, with a 2-daynLockTime refund back to Bob

H H


40/54


Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

HTLC 2-day

nLockTime

Carol & Dave create an HTLC output in the paymentchannel to pay Dave 0.01 BTC, with a 1-daynLockTime refund back to Carol

Dave can now get 0.01 BTC if she discloses R toCarol

H H

HTLC

nLockTim


41/54


Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

HTLC 2-day

nLockTime

Dave discloses Rto Carol within 1 day. Carol nowhas enough information to pull funds from Bob.

Carol and Dave agree to update the balances in thechannel instead of broadcasting on the blockchain

H H R

0.01


42/54


Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

Carol discloses Rto Bob within 2 days. Bob now hasenough information to pull funds from Alice.

Bob and Carol agree to update the balances in thechannel instead of broadcasting on the blockchain

H H RR

0.01

0.01 BTC


43/54


Alice

Bob Carol

HH

Bob discloses Rto Alice within 3 days. Alice canprove she sent funds to Dave.

Alice and Bob agree to update the balances in thechannel instead of broadcasting on the blockchain

H H RR

R

0.01

0.01 BTC

0.01

BTC

RHBroken


44/54

Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

If Bob and Carol dont cooperate, Carol immediatelycloses out the channel and broadcasts all pendingtransactions in the channel onto the blockchain.

Carol redeems the 0.01 by disclosing the HTLCoutput and Ron the Bitcoin blockchain.

H H R

0.01

Blockchain

RH

0.01 BTC

Broken

Channel

Broken RH


45/54

Broken

Channel

Alice

Bob Carol

HH

Bob observes R from the blockchain and can pullmoney from Alice off-chain.

H H R

0.01

Blockchain

0.01 BTC

0.01

BTC

R

R

Ti t


46/54

Timeout

Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

HTLC 2-day

nLockTime

If R never gets disclosed, timeouts occur sequentiallyfrom the destination.

This decrementing timeout ensures that everyonecan receive funds contingent upon it being sent

H H

HTLC

nLockTim

Ti t


47/54

Timeout

Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime

HTLC 2-day

nLockTime



H H

Ti t


48/54

Timeout

Alice

Bob Carol

HH

HTLC

3-day

nLockT

ime



H H

Ti t


49/54

Timeout

Alice

Bob Carol

HH

The HTLC has now timed out for all channels andevery party has updated their channel without theHTLC.

If one party is uncooperative, that channel isbroadcast on the blockchain.

H H

Implications


50/54

Implications

Blockchain transactions can be circuits instead

packets Only uncooperative channels get broadcast

the blockchain

Nearly all transactions occur off-chain secu

near-zero custodial default risk Creating new channels are infrequent

Relative OP_CHECKLOCKTIMEVERIFY Instant Transactions, Scalable Micropayments

Bit i C S l


51/54

Bitcoin Can Scale

7 billion people making 2 blockchaintransactions per day 24 GB blocks (~2,400 MB)

7e9 * 2txs * 250Bytes / 144 block/day

~50 Mbit/s best-case with IBLT @ 2tx/day/p

7 billion people roll-over 2 channels p 133 MB blocks - unlimited transactions coun

7e9 * 2 txs * 500Byte / 52560blocks/yr

~3 Mbit/s with IBLT

Bitcoin Can Scale


52/54

Bitcoin Can Scale

7 billion people making 20 blockchaintransactions per day 240 GB blocks (~24,000 MB)

7e9 * 20txs * 250Bytes / 144 block/day

~500 Mbit/s best-case with IBLT @ 20tx/day

7 billion people roll-over 2 channels p 133 MB blocks - unlimited transactions coun

7e9 * 2 txs * 500Byte / 52560blocks/yr

~3 Mbit/s with IBLT

Bitcoin Can Scale


53/54

Bitcoin Can Scale

Full Blockchain Archive 7 TB/year (7,000 GB) /w ~unlimited transac $300/year blockchain archival storage (2015

Blockchain Pruning

Server nodes and miners only keeping receand UTXOs have enough storage today (2 T

common in current-gen desktops)

Mobile Wallets (Lightweight SPV clien

Several megabytes of storage


54/54

Documents

Lightning Network Slide