FIT5214: Blockchain
Lecture 4: Proof-of-Work Lecturer:
https://dowsley.net
Copyright By PowCoder代写 加微信 powcoder
Unit Structure
• Lecture 1: Introduction to Blockchain
• Lecture 2: Bitcoin
• Lecture 3: Ethereum and Smart Contracts
• Lecture 4: Proof-of-Work (PoW)
• Lecture 5: Attacks on Blockchains
• Lecture 6: Class Test/Alternatives to PoW
• Lecture 7: Proof-of-Stake (PoS)
• Lecture 8: Privacy
• Lecture 9: Byzantine Agreement
• Lecture 10: Blockchain Network
• Lecture 11: Payment Channels
• Lecture 12: Guest Lecture
Unit Structure
• Lecture 1: Introduction to Blockchain
• Lecture 2: Bitcoin
Introduction to Bitcoin consensus
• Lecture 3: Ethereum and Smart Contracts ➡ How PoW consensus works;
• Lecture 4: Proof-of-Work (PoW)
• Lecture 5: Attacks on Blockchains
• Lecture 6: Class Test/Alternatives to PoW
• Lecture 7: Proof-of-Stake (PoS)
• Lecture 8: Privacy
• Lecture 9: Byzantine Agreement
• Lecture 10: Blockchain Network
• Lecture 11: Payment Channels
• Lecture 12: Guest Lecture
➡ Its impact on Bitcoin; Understand existing design flaws and attacks
Formal properties of PoW consensus
How to address/avoid some of them (some of them are open challenges)
How Bitcoin works? Recap!
1. How to create money?
2. How to spend money?
3. How to verify transactions? 4. Why do we need consensus?
Motivation
Let’s vote
Give my coin c_1 to my coin c_1 to Construction – Recap
1. Each block is referenced by the next block. e.g. H(block1) is included in the block2
2. Each block contains a set of transactions, organised as a Merkle tree
Ack: This picture is taken from ’s slides at Bitcoin summer school, Greece, 2016.
Bitcoin Puzzle – Recap
Find a Nonce such that
h(prev hash,Nonce,TX1,TX2,…,TXn) < D
where D is a di culty parameter.
• |Nonce| = 8 bytes • |TX| 250 bytes • h is SHA-256
• |block| 1 MB
• n is about 4,000
• D is recalculated every 2016 blocks (currently about 2 weeks)
The process of solving this puzzle is called “Mining”
Nakamoto Consensus
The longest chain wins! (Bitcoin assumes honest majority!)
Consensus Throughput
The number of transactions per second (TPS) Bitcoin can process.
Average: 115-200 TPS
Average: 1,700 TPS Peak time: 56,000 TPS
Consensus Throughput
Roughly speaking:
❖ Each block is 1MB
❖ Each transaction is about 256 bytes
❖ Each block contains about 4000 transactions
❖ Each block is created every 10 minutes
Group discussion:
1.If you are going to design a MonashCoin (as Bitcoin+), what are the potential ways to increase the throughput of Bitcoin transactions? Why?
2.Why is Bitcoin not already using your solution? What are the concerns?
Consensus Throughput
To increase throughput:
❖ Increase block size
❖ Decrease block creation time
❖ Graph of blocks to enable transaction inclusion in parallel
❖ Only record a “checksum” of transactions on the blockchain, and perform actual transactions in a payment channel (Week 11)
Why 10 minutes and 1MB?
It may not be the best choice:
❖ A new block should be created after most nodes learnt the previous block
❖ Disseminating blocks in the P2P network takes time
❖ Larger blocks take more time
❖ A shorter time creates more forks
❖ A shorter time reduces the difficulty of launching a double spending attack, unless the confirmation time is increased (details later)
Bitcoin ABC (Adjustable Blocksize Cap): 32MB per block Bitcoin SV (Satoshi's Vision): Potentially 2GB per block
Enforce Block Creation Time
How to guarantee 10 minutes per block? Difficulty parameter
Two weeks = 20160 minutes
14 days * 24 hours/day * 60 minutes/hour = 20160 minutes
10 minutes per block
2016 blocks in two weeks
Enforce Block Creation Time
How to guarantee 10 minutes per block? Difficulty parameter!
Four weeks One week
2016 blocks in two weeks
Do not change
Difficulty * 2 Difficulty * 1/2
Evolving Difficulty
https://www.blockchain.com/charts/difficulty?timespan=all
Bitcoin Consensus: Longest Chain Rule
#Votes = 3
#Votes = 2
Confirmation
The number of blocks “confirmed” the validity of a transaction
Transactions in block 1 has 2016 confirmations Transactions in block 2 has 2015 confirmations ...
Transactions in block 2015 has 2 confirmations Transactions in block 2016 has 1 confirmation
For security reasons, it is recommended to wait many confirmations (Are 6 confirmations good enough?)
Read more: https://en.bitcoin.it/wiki/Confirmation
Confirmation
Each block is created every 10 minutes
❖ 1 confirmation - 10 minutes
❖ 2 confirmation - 20 minutes ...
❖ 5 confirmation 50 minutes
❖ 6 confirmation 1 hour
Go and get coffee!
The number of blocks “confirmed” (the validity of a transaction)
Cappuccino please!
$5, thanks! BTC accepted.
Go and get coffee!
The number of blocks “confirmed” (the validity of a transaction)
OK, here is my Tx
OK, come back in an hour (6 confirmations)
What if no confirmation at all?
Group discussion:
1. What is the security problem if no confirmation is required?
2. Any solution you can propose?
Race Attack (0-confirmation)
OK, here is my Tx
OK, here is your coffee!
Race Attack (0-confirmation)
Create Tx’ to myself
Tx is invalid!
Tx is invalid!
The Tx is invalid!
Tx’ is invalid!
Tx is invalid!
Tx is invalid!
’ is invalid!
Tx’ is invalid!
Race Attack (0-confirmation)
More miners working on Tx’ rather than
Free coffee!
Requirement: Faster network
What is the assumption in this example?
(0-confirmation)
OK, here is my Tx
OK, here is your coffee!
Create Tx and Tx’
Create a block B containing Tx’
The entire network only accepts Tx’
Free coffee!
Requirement: Some mining power
(0-confirmation)
Alice launches a Finney attack as follows:
Step 1. Create a valid transaction TX_1 to transfer a coin to PK_Alice;
Alice does NOT broadcast TX_1!
Step 2. Create a valid block B containing TX_1 through block mining;
Alice does NOT broadcast the block, for now!
(So, to the network, the coin is unspent.)
Step 3. Create a valid transaction spending the coin to PK_service;
Step 4. Once the transaction is accepted by a 0-confirmation service, then broadcast B.
How about 1-confirmation?
Vector76 attack (Finney attack+Race attack)
1. Create two transactions Tx and Tx’
2. Create a block B containing Tx’
3. Send Tx to Payee
4. Wait for a block B’ containing Tx
(keep mining on B)
5. Send B to the network faster than B’
Finney attack: Step 1-4 Race attack: Step 5
Group Discussion
Group Discussion
1. What are the possible ways to gain extra advantages on including your own transaction? 2. Why?
3. How to fix?
More Confirmations?
51% Attack
c_1 to Jiangshan
c_1 to an attacker has >50% CPU power, it can spend a coin more than once.
51% Attack
What’s wrong?
The attack is on the Bitcoin consensus!
Terminology: Node
A node, or replica, is a single actor in the system.
❖ In a computer network, the computers are the nodes;
❖ In Blockchain, a node can be of different types:
❖ A client node is a node which only stores a part of the blockchain.
❖ A full node is a node which stores all the data of the blockchain;
e.g. blockchain explorer/backup server
NOTE: miners are full nodes!
❖ The total number of nodes in the system is “n”.
(unless otherwise specified)
❖ Each node may have different powers in voting, we call the total voting power in the system is “P”.
What is “consensus”?
Definition 1. (Consensus.) There are n nodes, of which at most f can be malicious, i.e., at least n f nodes are correct. For all i 2 [1, n], node i starts with an input value vi. The nodes must decide for one of those values, satisfying the following properties:
• Agreement: All correct nodes decide for the same value.
• Termination: All correct nodes terminate in finite time.
• Validity: The decision value must be the input value of a node.
Agreement cannot be reached
PoW consensus
Assuming a synchronous network, PoW guarantees eventual consistency, or more actually, nodes in PoW agrees on a Common Prefix of the blockchain.
Eventual Consistency
Eventually, all the nodes will agree on the same blockchain
…but some day in the future
Common Prefix
Global view:
Node 1: Node 2: Node 3:
PoW Consensus
Assuming a synchronous network, PoW guarantees eventual consistency, or more actually, nodes in PoW agrees on a Common Prefix of the blockchain.
T-consistency is used to quantify the quality of the blockchain consensus — after cutting down the last T blocks, all nodes should agree on the rest of the blockchain.
T-Consistency
Global view:
Node 1: Node 2: Node 3:
2-Consistency
T-Consistency
Global view:
Node 1: Node 2:
1-Consistency
The best consistency is 0-consistency, which can be provided by traditional consensus protocols (Week 9)
Chain Growth
Chain Quality
Adversarial contribution = 2/8 = 25%
Ideal Chain Quality
Is 51% attack feasible?
You need to control >51% hashing power in the world … of Bitcoin!!
Hard forks and competing coins reduce the mining power of a single chain!
51% Attacks
Assumption v.s. Reality
Assumption
13 July 2014
https://99bitcoins.com/wp-content/uploads/2014/06/PPVr0Wv.png
Mining Pool
Bitcoin mining process
Mining locally
latest block
Proof-of-Work Mining reward
Mining Pool
A single miner is likely to lose money
Electricity cost + machine cost > revenue
Bitcoin mining process
Mining Pool
1 Distribute mining tasks 2 Submit solutions
3 Claim rewards
4 Shares reward according to contribution
latest block
pool server
Proof-of-Work Mining reward
31-Jan.-2018
https://www.blockchain.com/en/pools
15 Oct 2018 >85% Mining power (14 pools) 52.5%
https://www.blockchain.com/en/pools
29 May 2019 90.8% Mining power (11 pools) 55.9%
Is 51% attack feasible?
https://coin360.com
PoW 51% Attack Cost
https://www.crypto51.app
Deconstructing Blockchains: A Comprehensive Survey on Consensus, Membership and Structure
https://arxiv.org/pdf/1908.08316.pdf
Take home message:
1. Blockchain is not as secure as you may think
2. There are many possible attacks on blockchains, including Bitcoin 3. Design details matter a lot!
4. DO NOT LAUNCH ATTACKS!
(You can try attacks in a testnet, but don’t do it on the real network!)
Try to find other possible attacks on Bitcoin-like system, and we will discuss next week!
(Ethics matters!)
Advanced attacks on blockchain next week!
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com