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

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

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 second @ 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

BITCOIN LIGHTNING NETWORK A possible solution of

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

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

Payment Channels: Unidirectional

Signed with Bob nLockTime, e.g. 30 days Payment Channels: Unidirectional Alice wants to pay to Bob Alice & Bob Multi-signature Account 1.0 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)

Payment Channels: Unidirectional (1st Tr.) Alice wants to pay to Bob Alice & Bob Multi-signature Account 0.9 for Alice 1.0 from Alice 0.1 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).

Payment Channels: Unidirectional (2nd Tr.) Alice wants to pay to Bob Alice & Bob Multi-signature Account 0.8 for Alice 1.0 from Alice 0.2 for Bob Signed by Alice, No nLock time Old transaction Signed with Bob nLockTime, e.g. 30 days 0.9 for Alice 0.1 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.

Payment Channels: Unidirectional (Closing) Alice wants to pay to Bob Alice & Bob Multi-signature Account 0.8 for Alice 1.0 from Alice 0.2 for Bob Signed by Alice, No nLock time Old transaction Signed with Bob nLockTime, e.g. 30 days 0.9 for Alice 0.1 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.

Payment Channels: Bidirectional

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 1.0 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.

Payment Channels: Bidirectional (1st Tr.) Alice wants to pay Bob Alice & Bob Multi-signature Account 0.9 for Alice 1.0 from Alice 0.1 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).

Payment Channels: Bidirectional (2nd Tr) Alice updates her payment to Bob Alice & Bob Multi-signature Account 0.8 for Alice 1.0 from Alice 0.2 for Bob Signed by Alice, nLock time, e.g. 29 days Signed with Bob nLockTime, e.g. 30 days 0.9 for Alice 0.1 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.

Payment Channels: Bidirectional (Reversing) Bob wants to pay Alice back Alice & Bob Multi-signature Account 0.9 for Alice 1.0 from Alice 0.1 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.

Payment Channels: Bidirectional (Closing) They want to close the channel Alice & Bob Multi-signature Account 0.9 for Alice 1.0 from Alice 0.1 for Bob Signed by Bob, nLock time, e.g. 28 days Signed with Bob nLockTime, e.g. 30 days 0.8 for Alice 0.2 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 0.9 for Alice 0.1 for Bob Signed by Alice, nLock time, e.g. 29 days

Payment Channels: Three-Party

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!

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

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

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

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)

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

BITCOIN LIGHTNING NETWORK: Payments

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.

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

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.

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.

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.

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.

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.

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

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

Thank You! Institute of Computer Science Cryptology Research Group

BACKUP SLIDES

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.

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.

Hashed Time-Lock Contract: