FAKULTÄT FÜR!NFORMATIK
Faculty of Informatics

S&P

SECURITY &PRIVACYGROUP

Atomic Multi-Channel Updates with Constant Collateralin Bitcoin-Compatible Payment-Channel Networks
Christoph Egger1, Pedro Moreno-Sanchez2, Matteo Maffei2@siccegge@pedrorechez@matteo_maffei

1Friedrich-Alexander-University, Erlangen-Nueremberg
2TU Vienna

Scaling Bitcoin
Tel Aviv, Sep12th 2019

Scalability Issues‣ Decentralized data structure recording eachtransaction in order to provide public verifiability‣ Global consensus: everyone checks the wholeblockchain
Bitcoin’s transaction rate: ~10 tx/sec
Visa’s transaction rate: ~10K tx/sec
2

Scalability Solutions?
‣ On-chain (tweak consensus)
e.g., DAG Blockchain, sharding, ...

‣ Off-chain (use blockchain only for disputes)
e.g., Payment Channel Networks
Lightning Network(Bitcoin)

Raiden Network(Ethereum)

Many other projects (Bolt, Perun, Liquidity Network…)

3

Scalability Solutions?
‣ On-chain (tweak consensus)
e.g., DAG Blockchain, sharding, ...

‣ Off-chain (use blockchain only for disputes)
e.g., Payment Channel Networks
Lightning Network(Bitcoin)

Raiden Network(Ethereum)

Many other projects (Bolt, Perun, Liquidity Network…)

3

Background on
Payment Channels

4Payment Channels: Open5Alice

1Bob

Blockchain

5

Payment Channels: OpenMultisig Contract

5

1

Can be spent only with thesignatures of both Alice and Bob

5 (Alice,Bob)
5 (Alice)

Alice

Alice

Bob

Blockchain‣ Alice creates multisig contract todeposit money on the channel

5Payment Channels: OpenMultisig Contract

5

1

Can be spent only with thesignatures of both Alice and Bob

5 (Alice,Bob)
5 (Alice)

Alice

Alice

Bob

5 (Alice)
5 (Alice,Bob)

Blockchain

Alice,Bob‣ Alice creates multisig contract todeposit money on the channel‣ Alice lets Bob sign a refund
transaction to unlock the money

5

Payment Channels: Open5Alice1Bob

5 (Alice)
5 (Alice,Bob)
Alice,Bob

Blockchain‣ Alice creates multisig contract to
5 (Alice,Bob)
5 (Alice)
Alicedeposit money on the channel‣ Alice lets Bob sign a refund
transaction to unlock the money‣ Alice places the multisig contract
onchain6

Payment Channels: Transactions
4

14 (Alice)
5 (Alice, Bob)
1 (Bob)

AliceBob
Alice ?? Bob

Blockchain

5 (Alice,Bob)
5 (Alice)
Alice
7

Payment Channels: Transactions
323 (Alice)
3 (Alice)
5 (Alice, Bob)
2 (Bob)2 (Bob)

Alice

Bob
Alice ?? Bob

Under the hood

Blockchain

Mechanisms for bidirectional payments
and for revocation of old states

5 (Alice,Bob)
5 (Alice)
Alice
8

Payment Channels: Close

Alice

Bob

Blockchain

5 (Alice,Bob)

3 (Alice)
5 (Alice, Bob)

5 (Alice)

2 (Bob)
Alice
Alice,Bob

Payment Channel Networks (PCNs)
4Alice12Bob

3CarolSend
1 BTC to Carol

One cannot open channels with everyone...
⇒ exploit channel paths!

10

Payment Channel Networks (PCNs)
41Alice

23Bob

CarolSend
1 BTC to Carol

32

Alice

2

Bob
1.

3CarolSend 1 BTC

10

Payment Channel Networks (PCNs)
41

Alice

32

BobCarolSend
1 BTC to Carol

32

Alice

Bob
1.

Carol

Send 1 BTC

3

Alice

32

12

Bob

4

2. Forward 1 BTC toCarol

Carol
10

Payment Channel Networks (PCNs)
4

1

Alice

BobSend
1 BTC to Carol

3

Carol
Should happen atomically

2

Alice

32

Bob
1.

Carol

Send 1 BTC

3

Alice

32

12

Bob

4

2. Forward 1 BTC toCarol

Carol
10

Payment Channel Networks (PCNs)
41

Alice

BobSend1 BTC to Carol

33-feefee

Carol
Should happen atomically

2Alice

32Bob
1.

Carol

1. Send 1 BTC + fee
Send 1 BTCto Bob

3-fee
3Alice32fee

2Fee acts as an incentive forBob to participate in thepayment

1Bob

4

2. Forward 1 BTC toCarol

Carol
10

Hashtime Lock Contract (HTLC)
41

54 (Alice)
4 (Alice)
5 (Alice, Bob)
1 (Bob)1 (Bob)

AliceyBob
Alice ?? Bob

11

Hashtime Lock Contract (HTLC)
4154 (Alice)
4 (Alice)
5 (Alice, Bob)
1 (Bob)1 (Bob)

Aliceyy

Bob

Alice ?? Bobx

With knowledge of x, Bob can“open”+ publish thetransaction on the blockchain
for enforcing the payment

11Hashtime Lock Contract (HTLC)
4

1

54 (Alice)
4 (Alice)
5 (Alice, Bob)
1 (Bob)1 (Bob)

AliceyxyBob

Alice ?? Bob
After time
thetransaction cannot be
published anymore onthe blockchain

With knowledge of x, Bob can“open”+ publish thetransaction on the blockchain
for enforcing the payment

11Hashtime Lock Contract (HTLC)
4154 (Alice)
4 (Alice)
5 (Alice, Bob)
1 (Bob)1 (Bob)

AliceyBoby
Alice ?? Bobx

After time
thetransaction cannot be
published anymore onthe blockchain

With knowledge of x, Bob can“open”+ publish thetransaction on the blockchain
for enforcing the payment

HTLC (Alice, Bob, 1, y,):Alice pays Bob 1 BTC iff Bob shows somex such that H(x) = y before

11HTLC for Multi-hop Payments

2

Alice

3

3

Bob

2

Carolxy:= H(x)12HTLC for Multi-hop Payments
y2

Alice

3

3

Bob

2

Carolxy:= H(x)12HTLC for Multi-hop Payments
yHTLC(Alice, Bob, 1.1, y, t)0.9 21.1

3

Alice

3

Bob

2Carolx1y:= H(x)12HTLC for Multi-hop Payments
yHTLC(Alice, Bob, 1.1, y, t)

0.9 21.1

HTLC(Bob, Carol, 1, y, t’)23

3

AliceBob

12Carolx

1y:= H(x)12HTLC for Multi-hop Payments
yHTLC(Alice, Bob, 1.1, y, t)

0.9 21.1

HTLC(Bob, Carol, 1, y, t’)

23

3

Alice

Bob
1

1 32x

Carol
xy:= H(x)12HTLC for Multi-hop Payments
yHTLC(Alice, Bob, 1.1, y, t)

0.9
0.921.1

Alice

HTLC(Bob, Carol, 1, y, t’)234.13x
1Bob

1 32x

Carolxy:= H(x)12HTLC for Multi-hop Payments
Requirement: t > t’(after yCarol revealed x to Bob, there
must still be time for Bob to reveal xto Alice)
HTLC(Alice, Bob, 1.1, y, t)

0.9
0.921.1

Alice

HTLC(Bob, Carol, 1, y, t’)

23

4.13x
1Bob

1 32x

Carolxy:= H(x)12Security and Privacy Issues in Existing
PCNs
ACMCCS

ND
201

7SS201913

Expressiveness and Collateral in
Payment-Channel Networks
ACMCCS

201

914

Open Challenges‣ In this work, we identify two open challenges:• Restricted expressiveness (and functionality)− Current Bitcoin-compatible PCNs restricted to single pathbased payments• High collateral− A payment requires to put aside coins for a very long time15

Improve Expressiveness Beyond Paths...
‣ So far we focused on single path-based payments‣ Atomic Multi-Path (AMP)1 payments: First step towards expressiveness

1 https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html

16

Our Goal: Full Expressiveness‣ Support for arbitrary graph topology‣ Enable new applications:‣ Crowd funding‣ Channel rebalancing‣ Netting‣ Your own application?

17

Collateralk+fees coinsnΔ timek coins
Δ time... n-2 channels ...

‣ Each payment of k coins along an n-channel path requires to put
aside at least kn coins‣ Also, each user i has to lock her coins for a time Δ(n-i) where Δ is
the time to safely close a channel‣ Coins locked too long!

18

Griefing attack
k+fees coinsnΔ timek coins
Δ time... n-2 channels ...

‣ The adversary has a time amplification factor of n-1‣ Δ is 1 day in the Lightning network!
‣ The attacker can use several paths

19

Our Goal: Constant Collateralk+fees coinsnΔ timek coins
Δ time... n-2 channels ...

20

Our Goal: Constant Collateralk+fees coinsnΔ timek+fees coins
Δ timek coins
Δ time... n-2 channels ...

‣ Constant collateral: Coins are locked only for Δ time,
independently of the number of channels

20Our Goal: Constant Collateralk+fees coinsnΔ timek+fees coins
Δ timek coins
Δ time... n-2 channels ...

‣ Constant collateral: Coins are locked only for Δ time,
independently of the number of channels‣ Reduces the amplification factor

20

Our Goal: Constant Collateralk+fees coinsnΔ timek+fees coins
Δ timek coins
Δ time... n-2 channels ...

‣ Constant collateral: Coins are locked only for Δ time,
independently of the number of channels‣ Reduces the amplification factor‣ Feasible in Ethereum-based PCNs: Sprites1

1 A. Miller et al. Sprites and State Channels: Payment Networks that Go Faster than Lightning.

20

Our Goal: Constant Collateralk+fees coinsnΔ timek+fees coins
Δ timek coins
Δ time... n-2 channels ...

‣ Constant collateral: Coins are locked only for Δ time,
independently of the number of channels‣ Reduces the amplification factor‣ Feasible in Ethereum-based PCNs: Sprites1

1 A. Miller et al. Sprites and State Channels: Payment Networks that Go Faster than Lightning.

20

Our Goal: Constant Collateralk+fees coinsnΔ timek+fees coins
Δ timek coins
Δ time... n-2 channels ...

‣ Constant collateral: Coins are locked only for Δ time,
independently of the number of channels‣ Reduces the amplification factor‣ Feasible in Ethereum-based PCNs: Sprites1

AMCU: Constant collateraland backwards compatible
with Bitcoin script

1 A. Miller et al. Sprites and State Channels: Payment Networks that Go Faster than Lightning.

20

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

21

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

Phase 1 (Setup for A,B)
(A1,B1): 10

Split the channel sothat 2 coins are stillavailable(A2,B2): 2

B1(A3,B3): 8
A1

21

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

Phase 1 (Setup for A,B)
(A1,B1): 10(A2,B2): 2

B1(A3,B3): 8
A1

Phase 2 (Lock for A,B)
After some Δ you getback the money (incase of failure in thenext phases)(A3,B3): 8
B3(A4,B4): 8A321

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

Phase 3 (Consume for A,B)
(A5,B5): 7.99

eAB: 0.01

B5

Phase 1 (Setup for A,B)
(A1,B1): 10(A2,B2): 2

B1(A3,B3): 8
A1A5

B6: 8To spend you needmoney in a freshaccount, which does
not have money yet,
key towards atomicity

Phase 2 (Lock for A,B)
(A3,B3): 8
B3(A4,B4): 8A321

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

Phase 3 (Consume for A,B)
eAB: 0.01(A5,B5): 7.99
B5Phase 1 (Setup for A,B)
(A1,B1): 10

B6: 8

A5

Phase 4 (Enable)(A2,B2): 2

B1(A3,B3): 8(A3,B3): 8

A3
B3
B’3
C3

A1

Phase 2 (Lock for A,B)

(B’3,C3): 7(A5,B5): 7.99

eAB: 0.01(B’5,C5): 6.99 eBC: 0.01

(A3,B3): 8
B3(A4,B4): 8A3

A Multi-In Multi-Out(MIMO) transaction
creates all fresh
addresses in one shot21

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

Phase 3 (Consume for A,B)
eAB: 0.01(A5,B5): 7.99
B5Phase 1 (Setup for A,B)
(A1,B1): 10

A5

Phase 4 (Enable)(A2,B2): 2

B1(A3,B3): 8
A1

Phase 2 (Lock for A,B)
(A3,B3): 8
B3(A4,B4): 8

B6: 8(A3,B3): 8A3
B3
B’3
C3(B’3,C3): 7(A5,B5): 7.99

eAB: 0.01(B’5,C5): 6.99 eBC: 0.01Setup —> Enable —> Consume
Setup —> LockA321

Atomic Multi-Channel Updates (ACMU)
8 (out of 10)

7 (out of 30)

Phase 3 (Consume for A,B)
eAB: 0.01(A5,B5): 7.99
B5Phase 1 (Setup for A,B)
(A1,B1): 10

A5

Phase 4 (Enable)(A2,B2): 2

B1(A3,B3): 8
A1

Phase 2 (Lock for A,B)

(A3,B3): 8A3
B3
B’3
C3(B’3,C3): 7(A5,B5): 7.99

eAB: 0.01(B’5,C5): 6.99 eBC: 0.01

Phase 5 (Disable)(A3,B3): 8(A7,B7): 8

B3A3

B6: 8(A4,B4): 8Solves ambiguous
state between Enableand Lock

A5
B5
B’5
C5

(B’7,C7): 7(A5,B5): 7.99

eAB: 0.01

eAB(B’5,C5): 6.99 eBC: 0.01
eBC

21

Security and Privacy Analysis‣ AMCU achieves atomicity. In particular:• If the coins at one channel are ready to be sent to expected
receiver, then all channels ready to forward payment• Otherwise, coins remain at a channel owned by original owners‣ AMCU does not achieve relationship anonymity• Every user in the path collaborates with each other‣ Instead,• Constant collateral (coins locked constant time)• Backwards compatible with current Bitcoin scripting language• Accountability: Possible to show a proof of misbehavior

22

Take Home...
‣ We can reduce the collateral to a constant and synchronize
multiple transaction atomically‣ Backwards compatible with Bitcoin script‣ Formally specified and proven secure in the UC Framework‣ Advantages:• Makes the collateral constant• Enables new classes of off-chain applications (e.g., crowd
funding, channel rebalancing and more?)‣ To be presented at ACM CCS 2019
‣ Paper available at https://eprint.iacr.org/2019/583.pdf

23

Take Home...
‣ We can reduce the collateral to a constant and synchronize
multiple transaction atomically‣ Backwards compatible with Bitcoin script‣ Formally specified and proven secure in the UC Framework‣ Advantages:• Makes the collateral constant• Enables new classes of off-chain applications (e.g., crowd
funding, channel rebalancing and more?)‣ To be presented at ACM CCS 2019
‣ Paper available at https://eprint.iacr.org/2019/583.pdf
THANKS!

@pedrorechez
23