1. Lightning or How to Pay Quickly with Bitcoin
Research Seminar In Cryptography
2017/2018 Spring
Lightning or How to Pay Quickly with Bitcoin
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
[J. Poon, T. Dryja 2016]
28 Nov 2017
Presentation: Karim Baghery
Supervisor: Michal Zajac
Coordinator: Dr. Vitaly Skachek

2. Contents: Motivation and Problem Statement
Transaction in Bitcoin are not instant & are expensive
Bitcoin does not scale
Construction of Bitcoin Lightning Network
Main idea
Payment channels
Unidirectional
Bidirectional
Three-party payments
Hash-locked contracts & Hashed Time-lock contracts
Payment by Bitcoin Lightning Network
An example

3. Problem Statement: Scalability & Real-time
Transaction in Bitcoin are not instant (~ 30 min – few hours)
The amount of network activity
Transaction fees
Bitcoin does not scale
With 1 MB blocks (every 10 min)
7 transactions per 250 bytes/tx
Not enough for whole the world
What determines the Bitcoin transaction times?
The two main factors influencing the transaction time are:
The amount of network activity
Transaction fees
Big number of transaction = huge amount of storages
How about larger block sizes?
The community does not approve bigger blocks
Small number of nodes, miners and difficult so validate  Centralization

4. BITCOIN LIGHTNING NETWORK
A possible solution of

5. Bitcoin Lightning Network: Introduction
Payment channels between many parties in a multi-hop network
Similar to internet routing
Minimally trusted intermediaries
Not possible to take other’s coins
Use block-chain as a trusted party in necessary cases
Currently lightning network can scale Bitcoin to billions of transactions per day

6. Payment Channels: Introduction
Creates Multi-Signature Account
e.g. You need all three keys to spent from the account
Allows two parties to send transactions to each other without hitting the Bitcoin blockchain
One of the essential concepts used in the Bitcoin Lightning Network
Alice
Bob

7. Payment Channels:
Unidirectional

8. Signed with Bob nLockTime, e.g. 30 days
Payment Channels: Unidirectional
Alice wants to pay to Bob
Alice & Bob Multi-signature Account
from Alice
Signed with Bob nLockTime, e.g. 30 days
Alice gets a refund signed by Bob with a particular nLockTime
Then Alice sends fund to the multi-signature address.
Even if Bob disappears, she can get the coins back in 30 days.
Via: OP_CHECKLOCKTIMEVERIFY (BIP 65)

9. Payment Channels: Unidirectional (1st Tr.)
Alice wants to pay to Bob
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Alice, No nLock time
Signed with Bob nLockTime, e.g. 30 days
Alice signs 0.1 to Bob, and gives Bob the signature.
Bob does not sign or broadcast (The signature itself is the payment).

10. Payment Channels: Unidirectional (2nd Tr.)
Alice wants to pay to Bob
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Alice, No nLock time
Old transaction
Signed with Bob nLockTime, e.g. 30 days
for Alice
for Bob
Signed by Alice, No nLock time
Alice signs 0.2 to Bob, overwriting the previous spend.
Alice can increment many times without transaction fees.

11. Payment Channels: Unidirectional (Closing)
Alice wants to pay to Bob
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Alice, No nLock time
Old transaction
Signed with Bob nLockTime, e.g. 30 days
for Alice
for Bob
Signed by Alice, No nLock time
Alice signs 0.2 to Bob, overwriting the previous spend.
Alice can increment many times without transaction fees.

12. Payment Channels:
Bidirectional

13. Signed with Bob nLockTime, e.g. 30 days
Payment Channels: Bidirectional
Alice and Bob both want to pay each other
Alice & Bob Multi-signature Account
from Alice
Signed with Bob nLockTime, e.g. 30 days
First Alice gets a refund signed by Bob, then sends fund to the multi-signature address.
Even if Bob disappears, she can get the coins back after 30 days.

14. Payment Channels: Bidirectional (1st Tr.)
Alice wants to pay Bob
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Alice, nLock time, e.g. 29 days
Signed with Bob nLockTime, e.g. 30 days
Alice signs 0.1 to Bob, and gives Bob the signature, but this time with an nLockTime smaller than Refund’s nLockTime (e.g. 29 days).
Bob does not sign or broadcast (The signature itself is the payment).

15. Payment Channels: Bidirectional (2nd Tr)
Alice updates her payment to Bob
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Alice, nLock time, e.g. 29 days
Signed with Bob nLockTime, e.g. 30 days
for Alice
for Bob
Signed by Alice, nLock time, e.g. 29 days
Alice signs 0.2 to Bob, overwriting the previous spend.
Alice can increment many times with the same nLockTime without transaction fees.

16. Payment Channels: Bidirectional (Reversing)
Bob wants to pay Alice back
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Bob, nLock time, e.g. 28 days
Signed with Bob nLockTime, e.g. 30 days
Bob signs 0.1 to Alice, and gives Alice the signature, but with an nLockTime smaller than Alice’s last nLockTime (e.g. 28 days).
Alice can broadcast first, so Bob does not get 0.2 Bitcoin
They can change the channel direction many times but each time they need to bring nLockTime closer to the present.

17. Payment Channels: Bidirectional (Closing)
They want to close the channel
Alice & Bob Multi-signature Account
for Alice
from Alice
for Bob
Signed by Bob, nLock time, e.g. 28 days
Signed with Bob nLockTime, e.g. 30 days
for Alice
for Bob
Signed by Alice, nLock time, e.g. 29 days
Close co-operatively via interactive multi-signature
Close non-copperatively with stored signature and timeout nLockTime
for Alice
for Bob
Signed by Alice, nLock time, e.g. 29 days

18. Payment Channels:
Three-Party

19. Payment Channels: Three-Party
Alice wants to pay Carol, they both have an active channel with Bob
1B to Carol
1B to Bob
Alice
Carol
Active Channel
Active Channel
Bob
They use these active channels to do the transaction off-chain
Problem 1: They need to trust Bob! Bob might keep the coins!
Problem 2: Carol might claim that she never got the coins!

20. Solution: Hash-Locked Contracts (HLC)
Payment Channels: Three-Party (Trustless)
Problem 1: They need to trust Bob! Bob might keep the coins!
Problem 2: Carol might claim that she never got the coins!
Solution: Hash-Locked Contracts (HLC)
Using one-way hash functions, Alice can prove she sent funds to Carol off-chain
Pay to Contract
Knowledge of secret R proves receipt, where H = h(R)
Receiver signs a contract stating if R is disclosed, funds have been received

21. Payment Channels: Three-Party with HLC
1B to Bob & H
Bob
1B to Carol & H
Alice
Carol
Active Channel
Active Channel H
Picks R
H = hash(R) H H
Carol picks a random number R, and computes H = hash(R)
Alice uses her channel with Bob and H to pay 1B
To spend it, Bob needs to know R
Bob does the same with Carol

22. Payment Channels: Three-Party with HLC
1B to Bob & H
Bob
1B to Carol & H R R
Alice
Carol
Active Channel
Active Channel R H R
Picks R
H = hash(R) H H
Carol redeems Bob’s transfer, revealing R
Bob does the same with Carol. He knows R and can spend Alice’s transfer.
Problem: What if Carol refuses to disclose R!
Channels expire

23. Solution: Hashed Time-Locked Contracts (HLC)
Payment Channels: Three-Party with HLC
1B to Bob & H
Bob
1B to Carol & H
Alice
Carol
Active Channel
Active Channel H
Picks R
H = hash(R) H H
Problem: What if Carol refuses to disclose R!
Channels expire
Solution: Hashed Time-Locked Contracts (HLC)

24. Hashed Time-Lock Contract: Alice & Bob
If Bob can produce to Alice input R from hash H within 3 days, Alice will pay Bob 1B
The above clause is void after 3 days
HTLC
Either party may agree to settle terms using other methods if both agree (off-chain or ...)
Violation of terms incurs a maximum penalty of funds in this contract …
0-nLockTime Requires R
3 days-nLockTime
Refund
Payment

25. BITCOIN LIGHTNING NETWORK:
Payments

26. Bitcoin Lightning Network: Routing
Alice wants to pay Dave 1B. Dave tells Alice, “Here is H, if you know R, consider your payment fulfilled”
Alice does not have a direct channel open with Dave, so she finds a route.

27. Dave can get fund if he disclose R to Carol
Bitcoin Lightning Network: Payments
HTLC 2-day
nLockTime
HTLC 3-day
nLockTime
HTLC 1-day
nLockTime
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H H H H
R , H = hash(R)
Alice & Bob create an HTLC output in the payment channel to pay Bob 1B, with a 3-day nLockTime refund back to Alice
Bob & Carol act similarly, but with 2-day nLockTime
Carol & Dave acts similarly, but with 1-day nLockTime
Dave can get fund if he disclose R to Carol

28. Bitcoin Lightning Network: Payments
HTLC 2-day
nLockTime
HTLC 3-day
nLockTime
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H H R H
R , H = hash(R)
Dave discloses R to Carol within 1 day.
Carol now has enough information to pull funds from Bob.
Carol and Dave agree to update the balances in the channel instead of broadcasting on the blockchain.

29. Bitcoin Lightning Network: Payments
HTLC 3-day
nLockTime
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H R H R H
R , H = hash(R)
Carol discloses R to Bob within 2 days.
Bob now has enough information to pull funds from Alice.
Bob and Carol agree to update the balances in the channel instead of broadcasting on the blockchain.

30. Bitcoin Lightning Network: Payments
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H R H R H R
R , H = hash(R)
Bob discloses R to Alice within 3 days and pulls funds (1B) from Alice.
Alice and Bob agree to update the balances in the channel instead of broadcasting on the blockchain.

31. Bitcoin Lightning Network: Broken Channel
Problem: What happens if Bob decides not to cooperate with Carol?!
Carol redeems the 1B by disclosing the HTLC output and R on the Bitcoin blockchain.
HTLC 2-day
nLockTime H R
HTLC 3-day
nLockTime
Channel
Channel
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H H R H
R , H = hash(R)
Carol immediately closes out the channel and broadcasts all pending transactions in the channel onto the blockchain.

32. Bitcoin Lightning Network: Broken Channel
Carol redeems the 1B by disclosing the HTLC output and R on the Bitcoin blockchain.
HTLC 2-day
nLockTime H R
Channel
Channel
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H R H R H R
R , H = hash(R)
Carol immediately closes out the channel and broadcasts all pending transactions in the channel onto the blockchain.
Bob observes R from the blockchain and can pull money from Alice off-chain.

33. Bitcoin Lightning Network: Timeout
HTLC 2-day
nLockTime
HTLC 3-day
nLockTime
HTLC 1-day
nLockTime
Bob
Carol
1 Bitcoin
1 Bitcoin
1 Bitcoin
Alice
Dave
Active Channel
Active Channel
Active Channel H H H
R , H = hash(R)
If R never gets disclosed, timeouts occur sequentially from the destination.
This decrementing timeout ensures that everyone can receive funds contingent upon it being sent

34. Transactions can be instant
Bitcoin Can Scale
Only uncooperative channels get broadcast early on the blockchain
Cheap Transactions
Nearly all transactions occur off-chain
Creating new channels are infrequent

35. Thank You!
Institute of Computer Science
Cryptology Research Group

36. BACKUP SLIDES

37. Bitcoin Improvement Proposal (BIP)123 provides a categorization
16 Pay to script hash
Allows transactions to be sent to a script hash (address starting with 3) instead of a public key hash (addresses starting with 1). To spend bitcoins sent via P2SH, the recipient must provide a script matching the script hash, and data which makes the script evaluate to true. The recipient might need the signatures of several people to spend these bitcoins, or a password might be required, or the requirements could be completely unique.
65 CHECKLOCKTIMEVERIFY
CLTV allows a transaction output to be unspendable until some specific point of time in the future.[41]
112 CHECKSEQUENCEVERIFY
CSV enables making an address (starting with 3) which can't spend bitcoin received, for a specified amount of time after receiving. One can have a 2-of-3 multisig address, which times out to a backup rule, unless there is 2-of-3 consensus.

38. Bitcoin Improvement Proposal 65:
OP_CHECKLOCKTIMEVERIFY (BIP 65) can help when the refund goes to one person, but if the refund is split among 2 people, this can’t be specified in a script.

39. Hashed Time-Lock Contract: