S & P SECURITY & PRIVACY GROUP Security and Privacy for - - PowerPoint PPT Presentation

▶
s p
SMART_READER_LITE
LIVE PREVIEW

S & P SECURITY & PRIVACY GROUP Security and Privacy for - - PowerPoint PPT Presentation

Mar 28, 2023 661 likes •1.41k views

FAKULTT FR !NFORMATIK Faculty of Informatics S & P SECURITY & PRIVACY GROUP Security and Privacy for Payment Channel Networks Pedro Moreno-Sanchez Blockchain Summer School BDLT19 Vienna, Sep 2nd 2019 Blockchain Research

slide-1
SLIDE 1

FAKULTÄT FÜR !NFORMATIK

Faculty of Informatics

S&P

SECURITY & PRIVACY GROUP

Security and Privacy for Payment Channel Networks Pedro Moreno-Sanchez

Blockchain Summer School BDLT’19 Vienna, Sep 2nd 2019

slide-2
SLIDE 2

2

Blockchain Research Lab: Highlights

  • CoinShuffle: privacy-preserving protocol for

blockchain payments implemented in several cryptocurrencies wallets

  • AMHL: first solution for security, privacy and

interoperability issues with blockchain scalability

  • protocols. Implemented in LND (current Bitcoin

scalability protocol), KZen Network and COMIT Network

  • DLSAG: first scalability protocol with formal

guarantees for the Monero cryptocurrency. Under discussion in the Monero community for adoption.

  • Lots of work on:
  • Security verification and safe design of smart

contracts

  • Privacy-preserving routing mechanisms
  • Constant collateral for Bitcoin-compatible PCNs
slide-3
SLIDE 3

3

Blockchain Research Lab: Collaborations

  • C. Schneidewind
  • E. Tairi
  • I. Grischchenko
  • M. Maffei
slide-4
SLIDE 4

3

Blockchain Research Lab: Collaborations

  • C. Schneidewind
  • E. Tairi
  • I. Grischchenko
  • M. Maffei
slide-5
SLIDE 5

3

Blockchain Research Lab: Collaborations

  • C. Schneidewind
  • E. Tairi
  • I. Grischchenko
  • M. Maffei
  • A. Kate
  • G. Malavolta
  • C. Egger
  • S. Roos
  • I. Goldberg
  • A. Gervais
slide-6
SLIDE 6
  • Decentralized data structure recording each

transaction in order to provide public verifiability

  • Global consensus: everyone checks the whole

blockchain

4

Scalability Issues

Bitcoin’s transaction rate: ~10 tx/sec Visa’s transaction rate: ~10K tx/sec

slide-7
SLIDE 7
  • On-chain (tweak consensus) 


e.g., DAG Blockchain, sharding, ...

  • Off-chain (use blockchain only for disputes) 


e.g., Payment Channel Networks Many other research projects (Bolt, Z-Channels, Perun, Liquidity Network ...)

Lightning Network (Bitcoin) Raiden Network (Ethereum)

5

Scalability Solutions?

slide-8
SLIDE 8
  • On-chain (tweak consensus) 


e.g., DAG Blockchain, sharding, ...

  • Off-chain (use blockchain only for disputes) 


e.g., Payment Channel Networks Many other research projects (Bolt, Z-Channels, Perun, Liquidity Network ...)

Lightning Network (Bitcoin) Raiden Network (Ethereum)

5

Scalability Solutions?

slide-9
SLIDE 9

6

Background on Payment Channel Networks

slide-10
SLIDE 10

7

Payment Channels: Open

Alice Bob Blockchain

5 1

slide-11
SLIDE 11

7

Payment Channels: Open

Alice Bob Blockchain

Multisig Contract Can be spent only with the signatures of both Alice and Bob

5 1

5 (Alice) 5 (Alice,Bob) Alice

  • Alice creates multisig contract to

deposit money on the channel

slide-12
SLIDE 12

7

Payment Channels: Open

Alice Bob Blockchain

Multisig Contract Can be spent only with the signatures of both Alice and Bob

5 1

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

  • Alice creates multisig contract to

deposit money on the channel

  • Alice lets Bob sign a refund

transaction to unlock the money

slide-13
SLIDE 13

8

Payment Channels: Open

Alice Bob Blockchain

5 1

5 (Alice) 5 (Alice,Bob) Alice

5 (Alice,Bob) 5 (Alice) Alice,Bob
  • Alice creates multisig contract to

deposit money on the channel

  • Alice lets Bob sign a refund

transaction to unlock the money

  • Alice places the multisig contract
  • nchain
slide-14
SLIDE 14

9

Payment Channels: Transactions

Blockchain

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

4 1

Alice Bob

5 (Alice) 5 (Alice,Bob) Alice

slide-15
SLIDE 15

10

Payment Channels: Transactions

Blockchain

5 (Alice, Bob) 3 (Alice) 2 (Bob) Alice ?? Bob

3 2

Alice Bob

5 (Alice, Bob) 3 (Alice) 2 (Bob) Alice ?? Bob 5 (Alice) 5 (Alice,Bob) Alice Under the hood Mechanisms for bidirectional payments and for revocation of old states

slide-16
SLIDE 16

5 (Alice, Bob) 3 (Alice) 2 (Bob) Alice,Bob

Payment Channels: Close

Blockchain Alice Bob

5 (Alice) 5 (Alice,Bob) Alice

slide-17
SLIDE 17

12

Payment Channel Networks (PCNs)

4 1 2 3

Alice Bob Carol

Send 1 BTC to Carol

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

⇒

slide-18
SLIDE 18

12

Payment Channel Networks (PCNs)

4 1 2 3

Alice Bob Carol Bob

2 3 3 2

Carol Alice

1. Send 1 BTC Send 1 BTC to Carol

slide-19
SLIDE 19

12

Payment Channel Networks (PCNs)

4 1 2 3

Alice Bob Carol Bob

2 3 3 2

Carol Alice

1. Send 1 BTC Send 1 BTC to Carol

3 2 1 4

Alice Bob Carol

  • 2. Forward 1 BTC to

Carol

slide-20
SLIDE 20

Should happen atomically

12

Payment Channel Networks (PCNs)

4 1 2 3

Alice Bob Carol Bob

2 3 3 2

Carol Alice

1. Send 1 BTC Send 1 BTC to Carol

3 2 1 4

Alice Bob Carol

  • 2. Forward 1 BTC to

Carol

slide-21
SLIDE 21

Should happen atomically

12

Payment Channel Networks (PCNs)

4 1 2 3

Alice Bob Carol Bob

2 3 3 2

Carol Alice

1. Send 1 BTC Send 1 BTC to Carol

Fee acts as an incentive for Bob to participate in the payment

3 2 1 4

Alice Bob Carol

  • 2. Forward 1 BTC to

Carol

3-fee 2

f
 e
 e

3-fee 2

f
 e
 e

  • 1. Send 1 BTC + fee

to Bob

slide-22
SLIDE 22

13

The Lightning Network (LN)

slide-23
SLIDE 23

5

14

Hashtime Lock Contract (HTLC)

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

4 1

Alice Bob y

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

slide-24
SLIDE 24

5

14

Hashtime Lock Contract (HTLC)

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

4 1 4 1

Alice Bob y

x

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

y

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

slide-25
SLIDE 25

5

14

Hashtime Lock Contract (HTLC)

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

4 1 4 1

Alice Bob y

x

After time the transaction cannot be published anymore on the blockchain 5 (Alice, Bob) 4 (Alice) 1 (Bob) Alice ?? Bob

y

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

slide-26
SLIDE 26

5

14

Hashtime Lock Contract (HTLC)

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

4 1 4 1

Alice Bob y

x

HTLC (Alice, Bob, 1, y, ):

Alice pays Bob 1 BTC iff Bob shows some x such that H(x) = y before

After time the transaction cannot be published anymore on the blockchain 5 (Alice, Bob) 4 (Alice) 1 (Bob) Alice ?? Bob

y

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

slide-27
SLIDE 27

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

y:= H(x)

x

2 3

slide-28
SLIDE 28

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

y:= H(x)

x

y 2 3

slide-29
SLIDE 29

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

HTLC(Alice, Bob, 1.1, y, t) y:= H(x)

x

y 2 3

1.1 0.9

3 1

slide-30
SLIDE 30

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’) 2 2 1 y:= H(x)

x

y 2 3

1.1 0.9

3 1

slide-31
SLIDE 31

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’) 2 2 1 y:= H(x)

x

y x 2 3 2 3

1.1 0.9

3 1

slide-32
SLIDE 32

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’) 2 2 1 y:= H(x)

x

y x x 2 3 2 3

1.1 0.9

3 1

0.9

4.1

slide-33
SLIDE 33

3 2

15

HTLC for Multi-hop Payments

Alice Bob Carol

HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’) 2 2 1 y:= H(x)

x

y Requirement: t > t’ (after Carol revealed x to Bob, there must still be time for Bob to reveal x to Alice) x x 2 3 2 3

1.1 0.9

3 1

0.9

4.1

slide-34
SLIDE 34
  • Lightning Network & Co work allow us to perform payments offchain
  • fast, no confirmation delay
  • little fees
  • minimal information stored on the blockchain
  • secure and privacy-preserving (at a first glance...)
  • The blockchain is used only to mediate disputes...cool!

16

Take home...

HTLC (Alice, Bob, 1.1, y, t):

Alice pays Bob 1.1 BTC iff Bob shows some x such that H(x) = y before t days

3 2

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

2 2 1

y:= H(x) x y x x 2 3

2 3

1 0.

3 1

0.9 4.1
slide-35
SLIDE 35

17

Security + Privacy in PCNs

Are off-chain payments in PCNs privacy-preserving by default?

(individual payments are not recorded on the blockchain)

Are off-chain payments in PCNs secure?

(No honest participant looses money)

slide-36
SLIDE 36

17

Security + Privacy in PCNs

Are off-chain payments in PCNs privacy-preserving by default?

(individual payments are not recorded on the blockchain)

Are off-chain payments in PCNs secure?

(No honest participant looses money)

NO! NO!

slide-37
SLIDE 37

18

Security and Privacy Issues in Existing PCNs

ACM CCS 2017 NDSS 2019

slide-38
SLIDE 38

19

Security Issue: The Wormhole Attack

A C E1 E2

HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)

y:= H(x)

x

B

slide-39
SLIDE 39

19

Security Issue: The Wormhole Attack

A C E1 E2

HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)

y:= H(x)

x

x B

slide-40
SLIDE 40

19

Security Issue: The Wormhole Attack

A C E1 E2

HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)

y:= H(x)

x

x x B

slide-41
SLIDE 41

19

Security Issue: The Wormhole Attack

A C E1 E2

HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)

y:= H(x)

x

x x x B

slide-42
SLIDE 42

19

Security Issue: The Wormhole Attack

A C E1 E2

HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)

y:= H(x)

x

x x x B considers the payment to be failed and unlocks his funds after the timeout B

slide-43
SLIDE 43

19

Security Issue: The Wormhole Attack

A C E1 E2

HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)

y:= H(x)

x

x x x B considers the payment to be failed and unlocks his funds after the timeout B gets 1.3 (no payment to B) pays 1 (no payment from B) Attacker earns 0.3 BTC (own fees + B’s fee)

slide-44
SLIDE 44

20

Privacy Issues in HTLC Payments

A C E1 E2

HTLC(A,E1,v1,y,t1) HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3) HTLC(E2,C,v4,y,t4)

B A’ C’ Relationship Anonymity: On-path adversaries do not learn who pays to whom

HTLC(A,E1,v1,y’,t1) HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3) HTLC(E2,C,v4,y’,t4)

slide-45
SLIDE 45

20

Privacy Issues in HTLC Payments

A C E1 E2

HTLC(A,E1,v1,y,t1) HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3) HTLC(E2,C,v4,y,t4)

B A’ C’

pays to pays to

≈

pays to pays to

Relationship Anonymity: On-path adversaries do not learn who pays to whom

HTLC(A,E1,v1,y’,t1) HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3) HTLC(E2,C,v4,y’,t4)

slide-46
SLIDE 46

20

Privacy Issues in HTLC Payments

A C E1 E2

HTLC(A,E1,v1,y,t1) HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3) HTLC(E2,C,v4,y,t4)

B A’ C’

pays to pays to

≈

pays to pays to

Relationship Anonymity: On-path adversaries do not learn who pays to whom

HTLC(A,E1,v1,y’,t1) HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3) HTLC(E2,C,v4,y’,t4)

slide-47
SLIDE 47

20

Privacy Issues in HTLC Payments

A C E1 E2

HTLC(A,E1,v1,y,t1) HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3) HTLC(E2,C,v4,y,t4)

B A’ C’

pays to pays to

≈

pays to pays to

Relationship Anonymity: On-path adversaries do not learn who pays to whom

HTLC(A,E1,v1,y’,t1) HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3) HTLC(E2,C,v4,y’,t4)

slide-48
SLIDE 48

21

Solving Security and Privacy Issues in Payment Channel Networks

slide-49
SLIDE 49

22

Solving Security + Privacy Issues

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

Randomised conditions at each hop that can only be released by (exactly) the right neighbour’s key

slide-50
SLIDE 50

22

Solving Security + Privacy Issues

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

k3 k1 k2 k4

Setup phase for the distribution of individual “randomisation factors” for users at each hop Randomised conditions at each hop that can only be released by (exactly) the right neighbour’s key

slide-51
SLIDE 51

22

Solving Security + Privacy Issues

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

k3 k1 k2 k4

Setup phase for the distribution of individual “randomisation factors” for users at each hop

Desired Properties

No coin loss 1.Atomicity:
 If a user’s right lock gets

  • pened, he can open his

left lock 2.Consistency:
 A user can open his left lock only if his right lock was released 3.Relationship Anonymity:
 A user learns about no

  • ther participant of the

payment path than his direct neighbours No Wormhole Attacks Privacy Randomised conditions at each hop that can only be released by (exactly) the right neighbour’s key

slide-52
SLIDE 52

ECDSA-based construction

23

Anonymous Multi-hop-Locks (AMHL)

Ideal functionality

(capturing atomicity, consistency + relationship anonymity) Construction from homographic one- way functions Schnorr-based construction

provably realise in the UC framework

slide-53
SLIDE 53

ECDSA-based construction

23

Anonymous Multi-hop-Locks (AMHL)

Ideal functionality

(capturing atomicity, consistency + relationship anonymity) Construction from homographic one- way functions Schnorr-based construction ECDSA-based construction

provably realise in the UC framework compatible with Bitcoin, Ethereum, etc.

slide-54
SLIDE 54

24

ECDSA-based Secure PCNs

slide-55
SLIDE 55

25

Scriptless Scripts

y

slide-56
SLIDE 56

5

25

Scriptless Scripts

Alice
 (skA) Bob
 (skB) y AB

hypothetical “shared identity” skAB = skA * skB

Blockchain

slide-57
SLIDE 57

5

25

Scriptless Scripts

4 1

Alice
 (skA) Bob
 (skB) y AB

hypothetical “shared identity” skAB = skA * skB

Blockchain

5 (AB) 4 (Alice) 1 (Bob)

y

AB ??k 5 (Alice) 5 (AB) Alice

slide-58
SLIDE 58

5

25

Scriptless Scripts

4 1

Alice
 (skA) Bob
 (skB) y

Alice can retrieve secret k from full signature Bob gets sufficient information for checking that the “half signature” produced by Alice and Bob can be completed to a valid signature given k

AB

hypothetical “shared identity” skAB = skA * skB

Blockchain

5 (AB) 4 (Alice) 1 (Bob)

y

AB ??k 5 (Alice) 5 (AB) Alice

slide-59
SLIDE 59

26

Extension to Multi-hop Locks

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

(k4, C4) (k2, C2) (k3, C3) (k1 + k2 + k3 + k4)

k1*G (k1 + k2)*G (k1 + k2 + k3)*G

A C E1 E2 B

(k1 + k2 + k3 + k4)*G

slide-60
SLIDE 60

26

Extension to Multi-hop Locks

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

(k4, C4) (k2, C2) (k3, C3) (k1 + k2 + k3 + k4)

k1*G (k1 + k2)*G (k1 + k2 + k3)*G

A C E1 E2

(k1 + k2 + k3 + k4)

B

(k1 + k2 + k3 + k4)*G

slide-61
SLIDE 61

26

Extension to Multi-hop Locks

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

(k4, C4) (k2, C2) (k3, C3) (k1 + k2 + k3 + k4)

k1*G (k1 + k2)*G (k1 + k2 + k3)*G

A C E1 E2

(k1 + k2 + k3 + k4)

B

(k1 + k2 + k3 + k4)*G

(k1 + k2 + k3)

  • k4
slide-62
SLIDE 62

26

Extension to Multi-hop Locks

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

(k4, C4) (k2, C2) (k3, C3) (k1 + k2 + k3 + k4)

k1*G (k1 + k2)*G (k1 + k2 + k3)*G

A C E1 E2

(k1 + k2 + k3 + k4)

B

(k1 + k2 + k3 + k4)*G

(k1 + k2 + k3) (k1 + k2)

  • k3
  • k4
slide-63
SLIDE 63

26

Extension to Multi-hop Locks

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

(k4, C4) (k2, C2) (k3, C3) (k1 + k2 + k3 + k4)

k1*G (k1 + k2)*G (k1 + k2 + k3)*G

A C E1 E2

(k1 + k2 + k3 + k4)

B

(k1 + k2 + k3 + k4)*G

(k1 + k2 + k3) (k1 + k2) k1

  • k2
  • k3
  • k4
slide-64
SLIDE 64

26

Extension to Multi-hop Locks

Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)

(k4, C4) (k2, C2) (k3, C3) (k1 + k2 + k3 + k4)

k1*G (k1 + k2)*G (k1 + k2 + k3)*G

A C E1 E2

(k1 + k2 + k3 + k4)

B

(k1 + k2 + k3 + k4)*G

(k1 + k2 + k3) (k1 + k2) k1

A valid key can only be extracted from a valid key for the right lock

  • k2
  • k3
  • k4

Conditions look random 
 (as they differ by a secret random factor)

slide-65
SLIDE 65

27

ECDSA-based Scriptless Lock

x

R = r * G

σR = sign(r, sk, transaction)

secret key message secret randomness

Signature w.r.t. a (public) random elliptic curve point R

slide-66
SLIDE 66

27

ECDSA-based Scriptless Lock

x

R = r * G

σR = sign(r, sk, transaction)

secret key message secret randomness

shared signature using a shared key and a shared randomness rA*rB rA*rB*G skA*skB

AB

Signature w.r.t. a (public) random elliptic curve point R

slide-67
SLIDE 67

27

ECDSA-based Scriptless Lock

x

R = r * G

σR = sign(r, sk, transaction)

secret key message secret randomness

shared signature using a shared key and a shared randomness rA*rB rA*rB*G skA*skB

AB

embedding of random share (condition) k rA*rB*k*G rA*rB*k skA*skB

AB

Signature w.r.t. a (public) random elliptic curve point R

slide-68
SLIDE 68

27

ECDSA-based Scriptless Lock

x

R = r * G

σR = sign(r, sk, transaction)

secret key message secret randomness

shared signature using a shared key and a shared randomness rA*rB rA*rB*G skA*skB

AB

embedding of random share (condition) k rA*rB*k*G rA*rB*k skA*skB

AB

Signature w.r.t. a (public) random elliptic curve point R rA*rB rA*rB*k*G skA*skB

AB

“half signature” without k but still with respect to rA*rB*k*G

slide-69
SLIDE 69

27

ECDSA-based Scriptless Lock

x

R = r * G

σR = sign(r, sk, transaction)

secret key message secret randomness

shared signature using a shared key and a shared randomness rA*rB rA*rB*G skA*skB

AB

embedding of random share (condition) k rA*rB*k*G rA*rB*k skA*skB

AB

Signature w.r.t. a (public) random elliptic curve point R rA*rB rA*rB*k*G skA*skB

AB

“half signature” without k but still with respect to rA*rB*k*G Lock Protocol

AB AB

(skA, rA) (skB, rB) C=k*G, transaction

“1/3” signature σR,B “1/3” signature σR,A …

slide-70
SLIDE 70

27

ECDSA-based Scriptless Lock

x

R = r * G

σR = sign(r, sk, transaction)

secret key message secret randomness

shared signature using a shared key and a shared randomness rA*rB rA*rB*G skA*skB

AB

embedding of random share (condition) k rA*rB*k*G rA*rB*k skA*skB

AB

Signature w.r.t. a (public) random elliptic curve point R rA*rB rA*rB*k*G skA*skB

AB

“half signature” without k but still with respect to rA*rB*k*G Lock Protocol

AB AB

(skA, rA) (skB, rB) C=k*G, transaction

“1/3” signature σR,B “1/3” signature σR,A …

Hard for ECDSA as σR has a non-linear structure

slide-71
SLIDE 71

28

Properties/Evaluation

  • Security and Privacy proven formally (in the UC Framework)
  • Compatible with Bitcoin and current PCNs

✓Implemented in ✓Lightning Network (https://github.com/cfromknecht/tpec) ✓Kzen Network (https://github.com/KZen-networks/multi-hop-locks) ✓COMIT Network (https://github.com/coblox/ss-ecdsa-poc)

  • Reduces transaction size for conditional payments

✓Encoding of condition within signature

  • Makes settlement transactions indistinguishable from regular ones

(Fungibility)

  • Little overhead:

✓ < 500 bytes communication ✓ few ms computation

Alice,Bob ?? AB

⤳

AB ?k

⤳

slide-72
SLIDE 72
  • AMHLs are suitable for cross-currency usage

  • even with different primitive instantiations

✓ Inter-currency payment channels ✓ Atomic swaps

29

Interoperability

E C D S A DLOG

slide-73
SLIDE 73

30

Summary

The Wormhole Attack: 
 A novel attack on Payment Channel Network Security Concrete constructions of AMHLs that

… got implemented in Bitcoin’s Lightning Network … enable inter-blockchain Payment Channels … are efficient

AMHLs: A new primitive for secure + anonymous Payment Channel Networks