Historical perspective on payment channels in Bitcoin and some of the problems that emerge.
Patrick McCorry
�
paddykcl
PISAResearch
Lots of talks are about lightning.
Let’s consider designing protocols in the context of layer 2.
What is a channel?
Every party collectively authorises a new state of an application locally amongst themselves.
�The blockchain acts as a root of trust to guarantee:
Safety: Each party gets the coins they deserve
Liveness: The application will always progress
paddykcl
1 transaction to turn on channel
200+ transactions authorised off-chain
1 transaction to turn off channel
Ideal case: No latency, no fees, two transactions on the blockchain
Reduces load on the global network,
while retraining similar security guarantees
Spilman Payment Channels
Duplex Micropayment Channels
Lightning Channels
Payment channels
Only re-distribute deposit
2013
2014
2015+
Spilman Payment Channels
Duplex Micropayment Channels
Lightning Channels
Payment channels
Only re-distribute deposit
2013
2014
2015+
What is the big problem new constructions solve?
How to update “the state” locally between parties.
State = balance of Alice&Bob
Spilman One-way Channel
Funding
Spilman One-way Channel
Funding
One of the two spending conditions:
Spilman One-way Channel
Funding
One of the two spending conditions:
Block 1
Block 2
...
...
...
Block t
Funding
Refund
Spilman One-way Channel
Funding
B,
0.1 BTC
A
Input
Output
Payment Transaction 1
A,
0.9 BTC
Transaction History:
Alice sends Bob 0.1 BTC - 10:30pm 02/07/2016
Bob can sign and broadcast
this transaction
before time t to get his 0.1 btc
0.1 BTC
Block 1
Funding
Spilman One-way Channel
Funding
B,
0.6 BTC
A
Input
Output
Payment Transaction 2
A,
0.4 BTC
Bam! Another 0.5 BTC payment.
All payments effectively re-sign a new transaction and passes it to Bob.
0.5 BTC
Transaction History:
Alice sends Bob 0.1 BTC - 10:30pm 02/07/2016
Alice sends Bob 0.5 BTC – 10:32pm 02/07/2016
Block 1
Funding
Spilman One-way Channel
Funding
B,
1 BTC
A
Input
Output
Payment Transaction 3
A,
0 BTC
Eventually..
Alice will send all her coins to Bob.
0.4 BTC
Transaction History:
Alice sends Bob 0.1 BTC - 10:30pm 02/07/2016
Alice sends Bob 0.5 BTC – 10:32pm 02/07/2016
Alice sends Bob 0.4 BTC – 10:33pm 02/07/2016
Block 1
Funding
No more payments!
Bob will sign and broadcast the transaction
that pays *him* the most coins.
This is “replace by incentive”.
Spilman One-way Channel
Funding
B,
1 BTC
A B
Input
Output
Payment Transaction
A,
0 BTC
0.4 BTC
Block 1
Funding
Block 2
Spilman One-way Channel
Funding
Payment
0.4 BTC
Block 1
Funding
Block 2
Spilman One-way Channel
Funding
Payment
0.4 BTC
Block 1
Funding
Block 2
Spilman One-way Channel
Funding
Payment
0.4 BTC
Block 1
Funding
Block 2
Spilman One-way Channel
Funding
Payment
0.4 BTC
Block 1
Funding
Block 2
Spilman One-way Channel
Funding
0.4 BTC
Block 1
Funding
Block 2
Payment
What if we want
a bi-directional channel?
Replace by Timelock
Every time we change payment direction, decrement the time lock.
Replace by Timelock
Every time we change payment direction, decrement the time lock.
The new transaction must have a new expiry time �that is LESS than the previous transaction.
Replace by Timelock
Two spending conditions:
Funding
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
Replace by Timelock
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
Block 1
Block 2
...
Block 18
Block 19
Block 20
Funding
Funding
Refund is valid
Replace by Timelock
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
B,
0.1 BTC
A
Input
Output
Payment Transaction, t=19 days
A,
0.9 BTC
Bob receives 0.1 BTC from Alice
Expiry time is set to 19 days
0.1 BTC
Funding
Replace by Timelock
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
B,
0.1 BTC
A
Input
Output
Payment Transaction, t=19 days
A,
0.9 BTC
0.1 BTC
Block 1
Block 2
...
Block 18
Block 19
Block 20
Funding
Funding
Payment is valid on block 19
(Can be accepted before refund)
Replace by Timelock
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
B,
0.3 BTC
A
Input
Output
Payment Transaction, t=19 days
A,
0.7 BTC
0.3 BTC
Funding
Bob receives another 0.2 BTC (0.3 BTC total) from Alice
Expiry time does not change - replace by incentive!
He must broadcast this transaction after 19 days, but before 20 days.
Replace by Timelock
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
B,
0.3 BTC
A
Input
Output
Payment Transaction, t=19 days
A,
0.7 BTC
0.3 BTC
Block 1
Block 2
...
Block 18
Block 19
Block 20
Funding
Funding
New payment is still valid on block 19
(Can be accepted before refund)
Let’s change payment direction.
Bob pays Alice.
Replace by Timelock
B,
0 BTC
B
Input
Output
Payment Transaction 2, t=18
A,
1 BTC
0.3 BTC
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
Funding
Alice receives 0.1 BTC from Bob.
New expiry time = 18 blocks.
Replace by Timelock
B,
0 BTC
B
Input
Output
Payment Transaction 2, t=18
A,
1 BTC
0.3 BTC
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
Funding
Block 1
Block 2
...
Block 18
Block 19
Block 20
Funding
Payment 2 can be claimed on Block 18
Payment 1 is “replaced/invalidated” as it can only be claimed on Block 19
Replace by Timelock
B,
0 BTC
B
Input
Output
Payment Transaction 2, t=18
A,
1 BTC
0.3 BTC
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
Funding
Block 1
Block 2
...
Block 18
Block 19
Block 20
Funding
“Safety Time Gap” of 1 block
(not safe in practice, may need to be 10 blocks, etc)
Replace by Timelock
B,
0 BTC
B
Input
Output
Payment Transaction 2, t=18
A,
1 BTC
0.3 BTC
Refund Alice on (or after) block 20�OR
Alice and Bob must agree.
Funding
Alice can always claim the 1 BTC before Bob can try to reverse it using an old transaction.
… but she must be ONLINE and READY to broadcast for exactly block 18.
Can we do any better?
DMC tries to alleviate the “reduce expiry time” issue
Spilman Payment Channels
Duplex Micropayment Channels
Lightning Channels
Payment channels
Only re-distribute deposit
Pair of one-way channels
All payments are performed in the one-way channels.
Channels can be destroyed/recreated via invalidation tree
Replace Time Locks to ensure only recent branch can be broadcast.
Two components for DMC
Input
Output
Alice to Bob (A->B)
A,
1 BTC
B,
0 BTC
A
Input
Output
A,
0 BTC
B,
1 BTC
B
Bob to Alice (B->A)
Funding
Pair of Unidirectional Channels
Another approach to bi-directional payments
is to set up two unidirectional channels
A->B and B->A
Input
Output
Alice to Bob (A->B)
A,
0.7 BTC
B,
0.3 BTC
A
Input
Output
A,
0.5 BTC
B,
0.5 BTC
B
Bob to Alice (B->A)
Funding
Pair of Unidirectional Channels
Another approach to bi-directional payments
is to set up two unidirectional channels
A->B and B->A
0.3 BTC Payment
0.5 BTC Payment
Input
Output
Alice to Bob (A->B)
A,
0.5 BTC
B,
0.5 BTC
A
Input
Output
A,
0.8 BTC
B,
0.2 BTC
B
Bob to Alice (B->A)
Funding
Pair of Unidirectional Channels
Another approach to bi-directional payments
is to set up two unidirectional channels
A->B and B->A
0.2 BTC Payment
0.3 BTC Payment
Input
Output
Alice to Bob (A->B)
A,
0 BTC
B,
1 BTC
A
Input
Output
A,
0 BTC
B,
1 BTC
B
Bob to Alice (B->A)
Funding
Pair of Unidirectional Channels
Another approach to bi-directional payments
is to set up two unidirectional channels
A->B and B->A
0.5 BTC Payment
0.2 BTC Payment
No coins left to send!
Let’s destroy the pair of one-way channels (offchain),
And refill them! (offchain)
Replace by Time Lock Structure
Funding
100d
100d
100d
Setup
Invalidation Tree
Signed by both parties
K
Transaction with an Absolute Lock Time
Unidirectional Channel (Payment Transaction)
Unidirectional
Channels
Replace by Time Lock Structure
100d
100d
100d
Setup
Invalidation Tree
Signed by both parties
K
Transaction with an Absolute Lock Time
Unidirectional Channel (Payment Transaction)
Notation Legend
99d
100d
100d
Unidirectional
Channels
Funding
Replace by Time Lock Structure
100d
100d
100d
Setup
Invalidation Tree
Signed by both parties
K
Transaction with an Absolute Lock Time
Unidirectional Channel (Payment Transaction)
Notation Legend
99d
100d
100d
99d
100d
Unidirectional
Channels
Funding
Replace by Time Lock Structure
Signed by both parties
K
Transaction with an Absolute Lock Time
Unidirectional Channel (Payment Transaction)
Notation Legend
100d
100d
100d
Setup
Invalidation Tree
99d
100d
100d
99d
100d
99d
Unidirectional
Channels
Funding
So far… it has all been a bit clunky right?
Hard to get rid of expiry time, limits on throughput of channel, etc.
Lightning Channels fixes that.
Both parties must co-operate for each payment….
State #1: Current Balance
Lightning Channels�Poon & Dryja (2015)
Both parties must co-operate for each payment….
Step 1: Agree a new channel state that represents the new balance
State #2: New Balance
State #1: Current Balance
Lightning Channels�Poon & Dryja (2015)
Both parties must co-operate for each payment….
Step 1: Agree a new channel state that represents the new balance
Step 2: Revoke the previous channel state that represented the old balance
Revoked State #1
State #2: New Balance
Lightning Channels�Poon & Dryja (2015)
Both parties must co-operate for each payment….
Step 1: Agree a new channel state that represents the new balance
Step 2: Revoke the previous channel state that represented the old balance.
Repeat
State #1
State #2
State #3
State #4
Lightning Channels�Poon & Dryja (2015)
State #5: New Balance
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
State #9: New Balance
Lightning Channels�Poon & Dryja (2015)
State #8
State == Pair of Signed Transactions
One transaction for Alice
One transaction for Bob
Disclaimer:
I’m not showing the transactions since its quite complex to get on a slide.
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
BLOCKCHAIN
State #9: New Balance
Lightning Channels�Poon & Dryja (2015)
State #8
What happens if an old state is accepted into the blockchain?
What happens if an old state is accepted into the blockchain?
It triggers a dispute process:
A fixed time period for the non-broadcaster to respond and prove it was a revoked state.
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
State #9: New Balance
Lightning Channels�Poon & Dryja (2015)
State #8
BLOCKCHAIN
State #4
What needs to be broadcast in response?
The non-broadcaster of the old state must publish a justice transaction to claim all coins in the channel!
Replace by Revocation
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
State #9: New Balance
Lightning Channels�Poon & Dryja (2015)
State #8
BLOCKCHAIN
State #4
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
Lightning Channels�Poon & Dryja (2015)
State #9: New Balance
What do we need to create a Justice Transaction?
�“Some information” to later prove the old state was indeed revoked!
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
Lightning Channels�Poon & Dryja (2015)
State #9: New Balance
What do we need to create a Justice Transaction?
�“Some information” to later prove the old state was indeed revoked!
Party:
Preimage (or hash tip)
Watch Tower:
A signed justice transaction.
State #1
State #2
State #3
State #4
State #5
State #6
State #7
State #8
Lightning Channels�Poon & Dryja (2015)
State #9: New Balance
This is why watch towers are impractical TODAY in lightning.
O(N) storage: Tower must keep around a justice transaction for every in-channel update.
Every payment authorises a new “state”
There are several “state replacement” techniques:
But… problems emerge due to Bitcoin’s scripting facility and UTXO model when we try to remove the expiry time and throughput limitation.
Concretely, what problems emerge?
State and Transaction is intertwined
Single state transitions only
No way to update the blockchain within a dispute period to say “wait, there is a later valid state”.
Lightning specific: Make sure your node doesn’t crash.
If the latest state is lost, you will lose all your coins - if the counterparty is not friendly.
Slashing isn’t always great - it hurts reliability as accidental crash = malicious behabviour.
Remember - Satoshi Nakamoto - had no idea how layer 2 would evolve!
Bitcoin isn’t designed with layer 2 (or off-chain protocol design) in mind!
What about Ethereum?
Can we do any better if the platform’s scripting language is more expressive?
Spilman Payment Channels
Duplex Micropayment Channels
Lightning Channels
Raiden Channels
Payment channels
Only re-distribute deposit
Spilman Payment Channels
Duplex Micropayment Channels
Lightning Channels
Raiden Channels
Sprites Channels
(us!)
Perun Channels
Counterfactual
Kitsune�(us!)
State channels
gaming, voting, auctions, etc
Payment channels
Only re-distribute deposit
Kitsune Channels: What is sent to the blockchain?
σA, σB, hstatei , i
Signatures from both parties
Hash of state
H(gamestate,r)
State version �(Monotonic counter)
https://nms.kcl.ac.uk/patrick.mccorry/battleship.pdf
Kitsune Channels: What is sent to the blockchain?
Signatures from both parties
Hash of state
H(gamestate,r)
State version �(Monotonic counter)
The hstate associated with the largest version “i” is considered the most recent authorised off-chain state.
σA, σB, hstatei , i
The Dispute Process (Kitsune) �
Step 1: One party triggers the dispute and there is a fixed time period for all parties to submit the latest agreed off-chain state.
Block 1
Initiate Dispute
Initiate Dispute
One party can initiate the dispute process.
Sets a fixed time period for all parties to respond.
The Dispute Process (Kitsune) �
Step 2: Any party can submit “the latest agreed state” to the blockchain
Submit State (Hash) + Version
All parties can hash of latest state (alongside counter)
Block 1
Block 2
Block ...
Block N-1
Initiate Dispute
hstate,
i
Block 3
hstate, i+1
The Dispute Process (Kitsune) �
Step 3: After the dispute period has expired, the blockchain decides the final state of the app and the dispute is “resolved”.
Block 1
Block 2
Block ...
Block N-1
Block N
Initiate Dispute
hstate,
i
Block 3
hstate, i+1
Resolve Dispute
Resolve Dispute
hstate, i+1 stored as the final commitment
After the dispute is resolved...
The application is re-deployed and
its execution simply continues via the blockchain.
Why are the state channel designs really cool?
No expiry time
No transaction throughput limitation
We don’t sign transactions, but a “commitment to the state”.
Easy to support WatchTower services.
No clunkiness - super straight forward.
This isn’t “new” for the bitcoin community either. �There are real attempts to get this style of dispute process into Bitcoin
Slide from roasbeef’s �2018 BPASE talk.
Replace by Version!
New opcodes!
SIGHASH_NOINPUT to support Replace by Version (similar to state channel)
eltoo supports “temporary state” to let us tell the blockchain which state is really “the latest” during the dispute period.
Even if you don’t like Ethereum for whatever reason
Expressive smart contracts significantly simplify protocol design�
Smart contracts are not “just” about dapps, �but programmable and publicly verifiable third parties�
It solves the “coordination” problem, where parties cannot �appoint a single entity to run the protocol for them.
Even if you don’t like Ethereum for whatever reason
Expressive smart contracts significantly simplify protocol design�
Smart contracts are not “just” about dapps, �but programmable and publicly verifiable third parties�
It solves the “coordination” problem, where parties cannot �appoint a single entity to run the protocol for them.
Of course, it isn’t all rosey �in the Ethereum world either.
We should do our best to make it as �EASY as possible to design protocols in Bitcoin.
We should do our best to make it as �EASY as possible to design protocols in Bitcoin.
While Bitcoin “script” is simple, �it pushes complexity to the protocol design layer*
*There is a long-running joke that designing a protocol on top of Bitcoin gets you a top-tier academic paper, whereas in Ethereum it gets you a blog post.
We should do our best to make it as �EASY as possible to design protocols in Bitcoin.
While Bitcoin “script” is simple, �it pushes complexity to the protocol design layer*
This needs to be fixed, so let’s advance bitcoin.
*There is a long-running joke that designing a protocol on top of Bitcoin gets you a top-tier academic paper, whereas in Ethereum it gets you a blog post.
Thanks for listening!
Off-chain Summary from 2015:
http://homepages.cs.ncl.ac.uk/patrick.mccorry/paymentnetworks.pdf
Sprites - Speed up routing & state channels
https://arxiv.org/abs/1702.05812
Kitsune (and battleship):�https://nms.kcl.ac.uk/patrick.mccorry/battleship.pdf
PISA:
https://eprint.iacr.org/2018/582.pdf
Painting the landscape for off-chain�https://eprint.iacr.org/2019/360.pdf
paddykcl
PISAResearch