Proof of Work and Mining in Blockchain
Lecture 6: Proof of Work and Mining
Recap: Longest Chain Rule
Proof of Work
Mining and incentives
Reference: Chapter 2.4, Princeton University Press book
Oracle
Time is organized into
slots
Oracle selects one of the nodes
(public identities)
random
everyone can verify the unique
winner
The selected node is the
proposer
constitutes a block with transactions
validates transactions
includes hash pointer to previous block
signs the block
Elements of Bitcoin
Ownership and Transfer of Coins
Integrity maintained (no stealing of coins)
Tamper resistant to anyone other than the
winner
of that slot
Tamper evident if the winner changed the block later
Resistant to Denial of Service
No transactions can be permanently eclipsed
Liveness
Double Spend Attack
Adversary can point its block to an older part of the chain
Duplicate transaction inserted
Plausible Deniability
network latency
an offline user will not know which block came earlier
blocks have no wall clock reference (time stamps).
Longest Chain Rule
Nakamoto protocol
followed by participants when its their turn to propose a block
attach block to tip of the longest chain in its’ block tree
Confirmation rule
wait until the transaction is buried
k
-deep in the longest chain
Summary:
resistant to double spend attack
Implementation of the Oracle
Oracle
Duplicate transaction inserted
Time is organized into
slots
Oracle selects
one
of the nodes (public identities)
random
everyone can
verify
the unique
winner
Implementation
distributed
unique proposer
consensus: all honest users need to agree
Proof of Work
Proof of Work
Computation needed
Easy to verify the computation
Hash functions
Used to create a hash puzzle:
H(nonce | block) < threshold
Nodes independently compete to solve hash puzzles
approximates random selection of proposer
hash threshold decides proposal rate
Bitcoin implements the oracle via Proof of Work
Hash Puzzles
Hash puzzle
H(nonce | block) < threshold
only way to solve hash puzzle is to guess try random
nonce
Total hash power
number of hashes that can be computed per second
total compute capacity over all nodes in the network
time varying
Hardness
threshold decides hardness
first
m
bits of hash value are 0
Proposal Rate
Hash puzzle
H(nonce | block) < threshold
threshold: first
m
bits of hash value are 0
Modeling puzzle solution
Each nonce attempt: Bernoulli random variable
Number of nonces until succss: Geometric random variable
Proposal process
rate decided by threshold and total hash power
modeled by Poisson random process
Success probability of an individual node
fraction of total hash power
Benefits of Proof of Work
Sybil resistance
individual success only depends on the hash power
no benefit in splitting the compute resource
Grinding resistance
puzzle hardness does not depend on the
content
of block
no benefit to choosing block content to match a given nonce
Adaptive
threshold can be varied over time
depending on how total hash power evolves (nodes enter/exit)
Bitcoin: threshold target recalculated every 2016 blocks
(roughly once in 2 weeks)
Incentives
Proposal requires work
Key part of the system
Ideally everyone should participate
Incentives
Block rewards
Transaction rewards
Block rewards
New coins
Coinbase transaction
Transaction rewards
Awarded by the source of the transaction
Block and Transaction Rewards
Need to be agreed in a distributed way
changing over time
Block rewards
Only way new coins enter the system
More rewards early in the system to incentivize early adopters
Bitcoin parameters
block rewards halves every 210K blocks
roughly every 4 yeard
zero block reward by 2140
Transaction rewards
Auction
G
Proposing
Voting
-deep
1 deep => .45
25 deep => 0.0006
Bitcoin protocol
Exploring the concepts of Proof of Work, Mining, Longest Chain Rule, Double Spend Attack, and the implementation of an Oracle in the context of Bitcoin. The content covers how time slots are organized, node selection, ownership and transfer of coins, integrity maintenance, resistance to attacks, and the confirmation rule to prevent double spending. The Nakamoto protocol, Oracle implementation, and the importance of consensus among users are highlighted as key components.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Lecture 6: Proof of Work and Mining Lecture 6: Proof of Work and Mining Recap: Longest Chain Rule Proof of Work Mining and incentives Reference: Chapter 2.4, Princeton University Press book
Oracle Oracle Time is organized into slots slots Oracle selects one of the nodes Oracle selects one of the nodes (public identities) random everyone can verify the unique winner The selected node is the The selected node is the proposer constitutes a block with transactions validates transactions includes hash pointer to previous block signs the block proposer
Elements of Bitcoin Elements of Bitcoin Ownership and Transfer of Coins Ownership and Transfer of Coins Integrity maintained (no stealing of coins) Tamper resistant to anyone other than the winner of that slot Tamper evident if the winner changed the block later Resistant to Denial of Service Resistant to Denial of Service No transactions can be permanently eclipsed Liveness
Double Spend Attack Double Spend Attack Adversary can point its block to an older part of the chain Adversary can point its block to an older part of the chain Duplicate transaction inserted Plausible Deniability Plausible Deniability network latency an offline user will not know which block came earlier blocks have no wall clock reference (time stamps).
Longest Chain Rule Longest Chain Rule Nakamoto protocol Nakamoto protocol followed by participants when its their turn to propose a block attach block to tip of the longest chain in its block tree attach block to tip of the longest chain in its block tree Confirmation rule Confirmation rule wait until the transaction is buried k-deep in the longest chain Summary: Summary: resistant to double spend attack
Implementation of the Oracle Implementation of the Oracle Oracle Oracle Duplicate transaction inserted Time is organized into slots Oracle selects one one of the nodes (public identities) random random everyone can verify verify the unique winner slots Implementation Implementation distributed unique proposer consensus: all honest users need to agree
Proof of Work Proof of Work Proof of Work Proof of Work Computation needed Easy to verify the computation Hash functions Hash functions Used to create a hash puzzle: H(nonce | block) < threshold Nodes independently compete to solve hash puzzles Nodes independently compete to solve hash puzzles approximates random selection of proposer hash threshold decides proposal rate Bitcoin implements the oracle via Proof of Work Bitcoin implements the oracle via Proof of Work
Hash Puzzles Hash Puzzles Hash puzzle Hash puzzle Total hash power Total hash power number of hashes that can be computed per second total compute capacity over all nodes in the network time varying Hardness Hardness threshold decides hardness first m bits of hash value are 0 H(nonce | block) < threshold only way to solve hash puzzle is to guess try random nonce
Proposal Rate Proposal Rate Hash puzzle Hash puzzle Modeling puzzle solution Modeling puzzle solution Each nonce attempt: Bernoulli random variable Number of nonces until succss: Geometric random variable Proposal process Proposal process rate decided by threshold and total hash power modeled by Poisson random process H(nonce | block) < threshold threshold: first m bits of hash value are 0 Success probability of an individual node Success probability of an individual node fraction of total hash power
Benefits of Proof of Work Benefits of Proof of Work Sybil resistance Sybil resistance individual success only depends on the hash power no benefit in splitting the compute resource Grinding resistance Grinding resistance puzzle hardness does not depend on the content of block no benefit to choosing block content to match a given nonce Adaptive Adaptive threshold can be varied over time depending on how total hash power evolves (nodes enter/exit) Bitcoin: threshold target recalculated every 2016 blocks (roughly once in 2 weeks)
Incentives Incentives Proposal requires work Proposal requires work Key part of the system Ideally everyone should participate Incentives Incentives Block rewards Transaction rewards Block rewards Block rewards New coins Coinbase transaction Transaction rewards Transaction rewards Awarded by the source of the transaction
Block and Transaction Rewards Block and Transaction Rewards Need to be agreed in a distributed way Need to be agreed in a distributed way changing over time Block rewards Block rewards Only way new coins enter the system More rewards early in the system to incentivize early adopters Bitcoin parameters Bitcoin parameters block rewards halves every 210K blocks roughly every 4 yeard zero block reward by 2140 Transaction rewards Transaction rewards Auction
Satoshis Table Bitcoin protocol 1 deep => .45 25 deep => 0.0006 Proposing Voting G low mining rate low mining rate low throughput low voting rate ?-deep high latency
