But Why Does it Work? A Rational Protocol Design Treatment of - - PowerPoint PPT Presentation

▶
but why does it work
SMART_READER_LITE
LIVE PREVIEW

But Why Does it Work? A Rational Protocol Design Treatment of - - PowerPoint PPT Presentation

Jan 31, 2024 270 likes •1.05k views

But Why Does it Work? A Rational Protocol Design Treatment of Bitcoin Christian Badertscher Juan Garay Ueli Maurer Daniel Tschudi ETH Zurich Texas A&M ETH Zurich ETH Zurich Vassilis Zikas University of Edinburgh & IOHK EUROCRYPT

slide-1
SLIDE 1

But Why Does it Work?

A Rational Protocol Design Treatment of Bitcoin

EUROCRYPT 2018

Ueli Maurer ETH Zurich Christian Badertscher ETH Zurich Vassilis Zikas University of Edinburgh & IOHK Daniel Tschudi ETH Zurich Juan Garay Texas A&M

slide-2
SLIDE 2

The Evolution of Bitcoin: A Partial View

Time

slide-3
SLIDE 3

The Evolution of Bitcoin: A Partial View

Time

2008/09 White Paper & Genesis

And Nakamoto said: Let there be Bitcoin…

slide-4
SLIDE 4

The Evolution of Bitcoin: A Partial View

Time

2008/09 White Paper & Genesis

And Nakamoto said: Let there be Bitcoin…

The Bitcoin community

slide-5
SLIDE 5

The Evolution of Bitcoin: A Partial View

Time

2008/09 White Paper & Genesis

And Nakamoto said: Let there be Bitcoin…

The Bitcoin community Rational analysis and attacks

  • Selfish Mining: Bitcoin is not an equilibrium

strategy [ES14]

  • ….
slide-6
SLIDE 6

The Evolution of Bitcoin: A Partial View

Time

2008/09 White Paper & Genesis

And Nakamoto said: Let there be Bitcoin…

The Bitcoin community Rational analysis and attacks

  • Selfish Mining: Bitcoin is not an equilibrium

strategy [ES14]

  • ….

Cryptographic analysis: Backbone (consensus layer) is secure if and only if the computing power of adversarial nodes does not form a majority [GKL15, PSS17 ]

slide-7
SLIDE 7

The Evolution of Bitcoin: A Partial View

Time

2008/09 White Paper & Genesis

And Nakamoto said: Let there be Bitcoin…

The Bitcoin community Rational analysis and attacks

  • Selfish Mining: Bitcoin is not an equilibrium

strategy [ES14]

  • ….

Cryptographic analysis: Backbone (consensus layer) is secure if and only if the computing power of adversarial nodes does not form a majority [GKL15, PSS17 ]

slide-8
SLIDE 8

The Evolution of Bitcoin: A Partial View

Time 2018

Bitcoin still works and no attack on its “backbone” has been observed!

2008/09 White Paper & Genesis

And Nakamoto said: Let there be Bitcoin…

The Bitcoin community Rational analysis and attacks

  • Selfish Mining: Bitcoin is not an equilibrium

strategy [ES14]

  • ….

Cryptographic analysis: Backbone (consensus layer) is secure if and only if the computing power of adversarial nodes does not form a majority [GKL15, PSS17 ]

slide-9
SLIDE 9

Why Does it Work?

Why don’t the predicted attacks

  • ccur and entirely break it?

Nostradamus

slide-10
SLIDE 10

Why Does it Work?

It doesn’t! Not an equilibrium. Just a temporary anomaly. Why don’t the predicted attacks

  • ccur and entirely break it?

Nostradamus

slide-11
SLIDE 11

Why Does it Work?

It doesn’t! Not an equilibrium. Just a temporary anomaly. Because the majority of computing power is controlled by honest miners Why don’t the predicted attacks

  • ccur and entirely break it?

Nostradamus

slide-12
SLIDE 12

Why Does it Work?

It doesn’t! Not an equilibrium. Just a temporary anomaly. Because the majority of computing power is controlled by honest miners

In game-theoretic analysis

  • Utilities = assumptions to

explain/predict players behavior

  • If predictions ≠ observable then

utilities (and game?) can (should?) be rethought.

Why don’t the predicted attacks

  • ccur and entirely break it?

Nostradamus

slide-13
SLIDE 13

Why Does it Work?

It doesn’t! Not an equilibrium. Just a temporary anomaly. but … why … ? Because the majority of computing power is controlled by honest miners

In game-theoretic analysis

  • Utilities = assumptions to

explain/predict players behavior

  • If predictions ≠ observable then

utilities (and game?) can (should?) be rethought.

Why don’t the predicted attacks

  • ccur and entirely break it?

Nostradamus

slide-14
SLIDE 14

Why Does it Work?

It doesn’t! Not an equilibrium. Just a temporary anomaly. but … why … ? Because the majority of computing power is controlled by honest miners

In game-theoretic analysis

  • Utilities = assumptions to

explain/predict players behavior

  • If predictions ≠ observable then

utilities (and game?) can (should?) be rethought. Can we back this up by a rational assumption?

  • Because the adversary has no

incentive to break it (either by corrupting majority or otherwise)

Why don’t the predicted attacks

  • ccur and entirely break it?

Nostradamus

slide-15
SLIDE 15

Why Does it Work?

It doesn’t! Not an equilibrium. Just a temporary anomaly. but … why … ? Because the majority of computing power is controlled by honest miners

In game-theoretic analysis

  • Utilities = assumptions to

explain/predict players behavior

  • If predictions ≠ observable then

utilities (and game?) can (should?) be rethought. Can we back this up by a rational assumption?

  • Because the adversary has no

incentive to break it (either by corrupting majority or otherwise)

Why don’t the predicted attacks

  • ccur and entirely break it?

Calls for an alternative rational treatment

Nostradamus

slide-16
SLIDE 16

Our Contributions

  • A new model for rational analysis of Bitcoin
  • Applying the framework to analyze the Bitcoin backbone
  • A class of utilities reflecting “minimal” assumptions about

the Bitcoin miners’ incentives.

  • Deriving predictions that match the observable.
slide-17
SLIDE 17

Our Contributions

  • A new model for rational analysis of Bitcoin
  • Applying the framework to analyze the Bitcoin backbone
  • A class of utilities reflecting “minimal” assumptions about

the Bitcoin miners’ incentives.

  • Deriving predictions that match the observable.

Blockchains

slide-18
SLIDE 18

Our Contributions

  • A new model for rational analysis of Bitcoin
  • Applying the framework to analyze the Bitcoin backbone
  • A class of utilities reflecting “minimal” assumptions about

the Bitcoin miners’ incentives.

  • Deriving predictions that match the observable.

Blockchains

slide-19
SLIDE 19

Securely implementing a task against an incentive-driven adversary

Rational Protocol Design (RPD) [GKMTZ13]

slide-20
SLIDE 20

Securely implementing a task against an incentive-driven adversary

(n-party) task as an ideal functionality F

Protocol Designer

uD

Protocol Attacker

uA

The Attack Game

Rational Protocol Design (RPD) [GKMTZ13]

slide-21
SLIDE 21

Securely implementing a task against an incentive-driven adversary

(n-party) task as an ideal functionality F

Protocol Designer

uD

Protocol Attacker

uA

The Attack Game

(n-party) protocol π for F

Rational Protocol Design (RPD) [GKMTZ13]

slide-22
SLIDE 22

Securely implementing a task against an incentive-driven adversary

Adversary A for attacking π

(n-party) task as an ideal functionality F

Protocol Designer

uD

Protocol Attacker

uA

The Attack Game

(n-party) protocol π for F

Rational Protocol Design (RPD) [GKMTZ13]

slide-23
SLIDE 23

Securely implementing a task against an incentive-driven adversary

Adversary A for attacking π

  • Utilities are defined in the ideal world as payoffs of

explicit “breaks” of F

  • zero-sum game (i.e., uD := - uA)

(n-party) task as an ideal functionality F

Protocol Designer

uD

Protocol Attacker

uA

The Attack Game

(n-party) protocol π for F

Rational Protocol Design (RPD) [GKMTZ13]

slide-24
SLIDE 24

Rational Protocol Design (RPD) [GKMTZ13]

Flavors of Protocol Quality (security / stability)

  • π is (uD, uA, ℿ)-attack-payoff optimal for F if any other protocol

in ℿ allows for more rewarding attacks

  • π is a best-response strategy among protocols in ℿ
  • π is (uD, uA, 𝔹)-attack-payoff secure for F if the best the attacker

can do is play an adversary in 𝔹

  • an 𝔹-adversary is best response to π

In [GKMTZ13]:

✴ ℿ = The class of all poly-time protocols ✴ 𝔹 = The class of all adversaries that honestly execute the protocol

slide-25
SLIDE 25

Rational Protocol Design (RPD) [GKMTZ13]

Flavors of Protocol Quality (security / stability)

  • π is (uD, uA, ℿ)-attack-payoff optimal for F if any other protocol

in ℿ allows for more rewarding attacks

  • π is a best-response strategy among protocols in ℿ
  • π is (uD, uA, 𝔹)-attack-payoff secure for F if the best the attacker

can do is play an adversary in 𝔹

  • an 𝔹-adversary is best response to π
slide-26
SLIDE 26

Flavors of Protocol Quality (security / stability)

  • π is (uD, uA, ℿ)-attack-payoff optimal for F if any other protocol

in ℿ allows for more rewarding attacks

  • π is a best-response strategy among protocols in ℿ
  • π is (uD, uA, 𝔹)-attack-payoff secure for F if the best the attacker

can do is play an adversary in 𝔹

  • an 𝔹-adversary is best response to π

Rational Protocol Design (RPD)++

slide-27
SLIDE 27

Flavors of Protocol Quality (security / stability)

  • π is (uD, uA, ℿ)-attack-payoff optimal for F if any other protocol

in ℿ allows for more rewarding attacks

  • π is a best-response strategy among protocols in ℿ
  • π is (uD, uA, (𝔹, ℿ) )-incentive compatible for F if it is (uD, uA, 𝔹)-

attack-payoff secure AND (uD, uA, ℿ)-attack-payoff optimal

  • π is (uD, uA, 𝔹)-attack-payoff secure for F if the best the attacker

can do is play an adversary in 𝔹

  • an 𝔹-adversary is best response to π

Rational Protocol Design (RPD)++

slide-28
SLIDE 28

Flavors of Protocol Quality (security / stability)

  • π is (uD, uA, ℿ)-attack-payoff optimal for F if any other protocol

in ℿ allows for more rewarding attacks

  • π is a best-response strategy among protocols in ℿ

For Bitcoin ✴ ℿ = The class of protocols that use the Bitcoin infrastructure (circulate blocks and transactions of the right format) ✴ 𝔹 = The class of semi-honest network-rushing adversaries ➡ strongly (uD, uA)-attack-payoff secure

  • π is (uD, uA, 𝔹)-attack-payoff secure for F if the best the attacker

can do is play an adversary in 𝔹

  • an 𝔹-adversary is best response to π

Bitcoin in RPD++

  • π is (uD, uA, (𝔹, ℿ) )-incentive compatible for F if it is (uD, uA, 𝔹)-

attack-payoff secure AND (uD, uA, ℿ)-attack-payoff optimal

slide-29
SLIDE 29

Bitcoin in RPD++

Protocol Designer

uD

Protocol Attacker

uA

(n-party) protocol π for F Adversary A for attacking π

  • Utilities are defined in the ideal world as payoffs of explicit

“breaks” of F

  • zero-sum game (i.e., uD := - uA)

2 2

(n-party) task as an ideal functionality F The Bitcoin Attack Game

1

slide-30
SLIDE 30

Bitcoin in RPD++

Protocol Designer

uD

Protocol Attacker

uA

(n-party) protocol π for F Adversary A for attacking π

  • Utilities are defined in the ideal world as payoffs of explicit

“breaks” of F

  • zero-sum game (i.e., uD := - uA)

2 2

(n-party) task as an ideal functionality F The Bitcoin Attack Game

1

slide-31
SLIDE 31

Buffer

Bitcoin an a Transaction Ledger [BMTZ17]

Gledger

B0 B1 B3

… Bs State

tx1 tx2 tx3 tx4 txl

slide-32
SLIDE 32

Buffer

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

(sufficiently long prefix of) B1,…,BS

Gledger

B0 B1 B3

… Bs State

tx1 tx2 tx3 tx4 txl

slide-33
SLIDE 33

Buffer

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

(sufficiently long prefix of) B1,…,BS

(Submit, tx)

Gledger

B0 B1 B3

… Bs State

tx1 tx2 tx3 tx4 txl

slide-34
SLIDE 34

Buffer

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

(sufficiently long prefix of) B1,…,BS

(Submit, tx)

Gledger

B0 B1 B3

… Bs State

tx1 tx2 tx3 tx4 txl

tx

Validate(.)

slide-35
SLIDE 35

Buffer

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

(sufficiently long prefix of) B1,…,BS

(Submit, tx)

Gledger

B0 B1 B3

… Bs State

tx1 tx2 tx3 tx4 txl

tx

Validate(.)

slide-36
SLIDE 36

Buffer

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

(sufficiently long prefix of) B1,…,BS

(Submit, tx)

Gledger

B0 B1 B3

… Bs State

tx1 tx2 tx3 tx4 txl

tx

tx

Validate(.)

tx

slide-37
SLIDE 37

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer

tx1 tx2 tx3 tx4 txl

tx

(sufficiently long prefix of) B1,…,BS

slide-38
SLIDE 38

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer

tx1 tx2 tx3 tx4 txl

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-39
SLIDE 39

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx1 tx2 tx3 tx4 txl

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-40
SLIDE 40

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx1 tx2 tx3 tx4 txl

Extend Policy

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-41
SLIDE 41

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx1 tx2 tx3 tx4 txl

Extend Policy

tx

Next Block

tx1,tx3

  • chain growth, chain quality,…

[GKL15,PSS17]

(sufficiently long prefix of) B1,…,BS

slide-42
SLIDE 42

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx1 tx2 tx3 tx4 txl

Extend Policy

tx

Next Block

tx1,tx3

  • chain growth, chain quality,…

[GKL15,PSS17]

(sufficiently long prefix of) B1,…,BS

slide-43
SLIDE 43

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx1 tx2 tx3 tx4 txl

Extend Policy Blockify

tx

Next Block

tx1,tx3

  • chain growth, chain quality,…

[GKL15,PSS17]

(sufficiently long prefix of) B1,…,BS

slide-44
SLIDE 44

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx1 tx2 tx3 tx4 txl

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

  • chain growth, chain quality,…

[GKL15,PSS17]

(sufficiently long prefix of) B1,…,BS

slide-45
SLIDE 45

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx2 tx1 tx3 tx4 txl

tx

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-46
SLIDE 46

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx2 tx1 tx3 tx4 txl

tx

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-47
SLIDE 47

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx2 tx1 tx3 tx4 txl

tx

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-48
SLIDE 48

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx2 tx1 tx3 tx4 txl

tx

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-49
SLIDE 49

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx2 tx4 txl

tx

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

(sufficiently long prefix of) B1,…,BS

slide-50
SLIDE 50

Bitcoin an a Transaction Ledger [BMTZ17]

GetState

Validate(.) No

Gledger

B0 B1 B3

… Bs State

Buffer time? t

tx2 tx4 txl

tx

Extend Policy Blockify

Bs+1

tx

Next Block

tx1,tx3

Bitcoin UC implements such a ledger against corrupted minority [BMTZ17] (sufficiently long prefix of) B1,…,BS

slide-51
SLIDE 51

Bitcoin in RPD++

Protocol Designer

uD

Protocol Attacker

uA

(n-party) protocol π for F Adversary A for attacking π

  • Utilities are defined in the ideal world as payoffs of explicit

“breaks” of F

  • zero-sum game (i.e., uD := - uA)

2 2

(n-party) task as an ideal functionality F FLedger The Bitcoin Attack Game

1

slide-52
SLIDE 52

Bitcoin in RPD++

Protocol Designer

uD

Protocol Attacker

uA

(n-party) protocol π for F Adversary A for attacking π

  • Utilities are defined in the ideal world as payoffs of explicit

“breaks” of F

  • zero-sum game (i.e., uD := - uA)

2 2

(n-party) task as an ideal functionality F FLedger The Bitcoin Attack Game

1

slide-53
SLIDE 53

Bitcoin in RPD++

Protocol Designer

uD

Protocol Attacker

uA

(n-party) protocol π for F Adversary A for attacking π

  • Utilities are defined in the ideal world as payoffs of explicit

“breaks” of F

  • zero-sum game (i.e., uD := - uA)

2 2

(n-party) task as an ideal functionality F FLedger The Bitcoin Attack Game

1

slide-54
SLIDE 54

Our Contributions

  • A new model for rational analysis of Bitcoin
  • Applying the framework to analyze the Bitcoin backbone
  • A class of utilities reflecting “minimal” assumptions about

the Bitcoin miners’ incentives.

  • Deriving predictions that match the observable.

Blockchains

slide-55
SLIDE 55

The Utilities

Parameters Block Reward BR (Unit : BTC) Hashing Cost HC (Unit : KWh) Transaction Fees TF (Unit : BTC)

(+) (+) (-)

Utility = expected rewards - expected costs

slide-56
SLIDE 56

The Utilities

Parameters Block Reward BR (Unit : BTC) Hashing Cost HC (Unit : KWh) Transaction Fees TF (Unit : BTC)

(+) (+) (-)

1KWh = CR BTC Utility = expected rewards - expected costs

slide-57
SLIDE 57

The Utilities

Parameters Block Reward BR (Unit : BTC) Hashing Cost HC (Unit : KWh) Transaction Fees TF (Unit : BTC)

(+) (+) (-)

1KWh = CR BTC Utility = expected rewards - expected costs

slide-58
SLIDE 58

The Utilities

Parameters Block Reward BR (Unit : BTC) Hashing Cost HC (Unit : KWh) Transaction Fees TF (Unit : BTC)

(+) (+) (-)

1KWh = CR BTC

The attacker’s (expected) utility : Wants to make profit

  • For each block a corrupted inserts into the state: (BR + TF) BTCs
  • For each hash query a corrupted makes: - (HC x CR) BTCs

uB

A

Utility = expected rewards - expected costs

slide-59
SLIDE 59

The Utilities

Parameters Block Reward BR (Unit : BTC) Hashing Cost HC (Unit : KWh) Transaction Fees TF (Unit : BTC)

(+) (+) (-)

1KWh = CR BTC

Can be defined in the ideal experiment (explicit in the functionality)

The attacker’s (expected) utility : Wants to make profit

  • For each block a corrupted inserts into the state: (BR + TF) BTCs
  • For each hash query a corrupted makes: - (HC x CR) BTCs

uB

A

Utility = expected rewards - expected costs

slide-60
SLIDE 60

The Utilities

Parameters Block Reward BR (Unit : BTC) Hashing Cost HC (Unit : KWh) Transaction Fees TF (Unit : BTC)

(+) (+) (-)

The designer’s (expected) utility : Wants to preserve consensus and make profit while doing so

  • For each block an honest inserts into the state: (BR + TF) BTCs
  • For each hash query an honest makes: - (HC x CR) BTCs

uB

D

  • If the state (permanent part) of the ledger forks then - exp BTCs

1KWh = CR BTC Utility = expected rewards - expected costs

slide-61
SLIDE 61

Bitcoin in RPD++

Advantages over standard rational analysis

  • Simpler (Stackelberg) game to analyze
  • 2-party 2-move metagame among unbounded agents
  • Most Bitcoin miners will not cheat and will follow the

protocol if it is profitable for them

  • Utilities are defined in the cleaner ideal world
  • Can define them based on the fixed ledger state rather

than local views of parties

  • Automatic composition with crypto [GKMTZ13]
  • Easily captures adaptive corruption
  • Example: bribery attacks [Bon16]
slide-62
SLIDE 62

Our Contributions

  • A new model for rational analysis of Bitcoin
  • Applying the framework to analyze the Bitcoin backbone
  • A class of utilities reflecting “minimal” assumptions about

the Bitcoin miners’ incentives.

  • Deriving predictions that match the observable.

Blockchains

slide-63
SLIDE 63

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is strongly

  • attack-payoff secure for FLedger

(uB

D, uB A)

slide-64
SLIDE 64

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is strongly

  • attack-payoff secure for FLedger

Recall: This is the semi-honest network-rushing adversary

(uB

D, uB A)

slide-65
SLIDE 65

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is strongly

  • attack-payoff secure for FLedger

Recall: This is the semi-honest network-rushing adversary

Proof Idea:

  • The adversary controls the network
  • Any non-network related attack involves hashing
  • If the finds a solution to the puzzle he is better off

pushing it to the network

  • Otherwise, the hash is useless (and costly)

(uB

D, uB A)

slide-66
SLIDE 66

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is strongly

  • attack-payoff secure for FLedger

Recall: This is the semi-honest network-rushing adversary

Proof Idea:

  • The adversary controls the network
  • Any non-network related attack involves hashing
  • If the finds a solution to the puzzle he is better off

pushing it to the network

  • Otherwise, the hash is useless (and costly)

(uB

D, uB A)

Fixed difficulty

slide-67
SLIDE 67

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if and only if CR is "high enough” (uB

D, uB A

slide-68
SLIDE 68

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if and only if CR is "high enough”

BR · CR > HC · 1 p · (1 − p)n−1

BR · CR < HC p

* p = Probability of finding a valid block in 1 hash query

(uB

D, uB A

slide-69
SLIDE 69

Stability/Security: No Transaction Fees (TF=0)

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if and only if CR is "high enough” Proof Idea: On expectation, the cost of mining till you find a block is more than the profit (even if the block would make it)

BR · CR > HC · 1 p · (1 − p)n−1

BR · CR < HC p

* p = Probability of finding a valid block in 1 hash query

(uB

D, uB A

slide-70
SLIDE 70

Stability/Security: No Transaction Fees (TF=0)

Proof Idea: On expectation, the cost of mining till you are the only

  • ne that finds a block is less than the profit.

BR · CR > HC · 1 p · (1 − p)n−1

BR · CR < HC p

* p = Probability of finding a valid block in 1 hash query

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if and only if CR is "high enough” (uB

D, uB A

slide-71
SLIDE 71

Stability/Security: With Transaction Fees

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if CR is "high enough” and … (uB

D, uB A

slide-72
SLIDE 72

Stability/Security: With Transaction Fees

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if CR is "high enough” and …

  • no incentive to circulate high-fee transactions

to the network

(uB

D, uB A

slide-73
SLIDE 73

Stability/Security: With Transaction Fees

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if CR is "high enough” and …

  • no incentive to circulate high-fee transactions

to the network

(uB

D, uB A

  • there is an upper bound on total fees
  • all parties get enough transactions to

reach this bound

slide-74
SLIDE 74

Stability/Security: With Transaction Fees

Bitcoin is

  • incentive-compatible for FLedger

B A, (A, Π))

if CR is "high enough” and …

  • no incentive to circulate high-fee transactions

to the network

(uB

D, uB A

  • there is an upper bound on total fees
  • all parties get enough transactions to

reach this bound

Proposal for when rewards approach zero

slide-75
SLIDE 75

Conclusions

Our Results

  • Simple and Crypto-compatible rational model for blockchains
  • Rational treatment of the Bitcoin backbone with fixed difficulty

under natural minimal utilities

  • The effect of exchange on stability/security
  • Proposal for coping with diminishing rewards
  • Also in the paper: Rationality as a fallback to honest majority
slide-76
SLIDE 76

Conclusions

Our Results

  • Simple and Crypto-compatible rational model for blockchains
  • Rational treatment of the Bitcoin backbone with fixed difficulty

under natural minimal utilities

  • The effect of exchange on stability/security
  • Proposal for coping with diminishing rewards
  • Also in the paper: Rationality as a fallback to honest majority

Future Directions

  • Variable difficulty
  • Utilities capturing other factors might affect the decision:
  • Detection of a 50% attack might be a deterrence
  • Mining pools’ incentives
  • A rational analysis of Bitcoin as cryptocurrency
  • The contents of transactions might affect the utilities…
slide-77
SLIDE 77

Conclusions

Our Results

  • Simple and Crypto-compatible rational model for blockchains
  • Rational treatment of the Bitcoin backbone with fixed difficulty

under natural minimal utilities

  • The effect of exchange on stability/security
  • Proposal for coping with diminishing rewards
  • Also in the paper: Rationality as a fallback to honest majority

Future Directions

  • Variable difficulty
  • Utilities capturing other factors might affect the decision:
  • Detection of a 50% attack might be a deterrence
  • Mining pools’ incentives
  • A rational analysis of Bitcoin as cryptocurrency
  • The contents of transactions might affect the utilities…

Thank you!