Bitcoin Consensus Mechanism——SYSU SSE Blockchain 5th lecture(English Version)

Consistency: All changes are seen by all nodes at the same time.
Availability: Systems return a response within an acceptable time frame.
Partition Tolerance: The system continues to function when network segments fail to communicate. Systems can be partitioned into sub-networks that continue to function independently.

Trade-offs ("Pick Two" Dilemma)

Availability ≠ Correctness: You can only achieve two out of the three CAP properties in a distributed system.
CA/P: Focuses on consistency and availability but lacks partition tolerance.
- Implementation: All data is stored on a single node, and other nodes read from this main node.
- Note: Not considered a distributed system.
CP/A: Focuses on consistency and partition tolerance at the cost of availability.
- Implementation: Each node stores data, with the primary focus on ensuring consistency.
AP/C: Focuses on availability and partition tolerance at the cost of consistency.
- Implementation: Each node stores data, with the primary focus on ensuring availability.

Note: Since distributed systems must have Partition Tolerance (P), they must choose between Consistency (C) and Availability (A).

Part 2: Why Bitcoin needs Consensus

Types of Consensus Mechanisms

BFT-based (Byzantine Fault Tolerance)
- Feature: Low computational requirements
- Participants: Permissioned, limited trust
- Applicability: Alliance/Private Chains
Leader Election-based
- Example: Proof of Work (PoW)
- Feature: Computationally intense
- Participants: Permissionless, anonymous, no trust
- Applicability: Public Chains

Why Bitcoin Needs Consensus

Byzantine Generals Problem

Problem: Uncertain transmission of information due to possible traitors
Goal: To maintain consistency in a distributed system
Solution:
- Simplified to a Generals and Lieutenants model
- Loyal Lieutenants follow the same command, traitors may disrupt
Fault Tolerance: Malicious nodes must be less than 1/3 of the total nodes

Sybil Attack

Consequence: Makes Byzantine Fault Tolerance unsuitable for Bitcoin
Method: Creating multiple identities to cast multiple votes
Why Feasible:
- Bitcoin is a decentralized, anonymous service
- Low cost to create multiple identities
Example: Double-spending attack
Defense: Resource-based voting through Proof of Work (PoW)

Bitcoin's Consensus Mechanism: Proof of Work (PoW)

What is Proof of Work?

Goal: To solve the Byzantine Generals Problem
Voting Eligibility: Granted through computational work

PoW Mining Principle

Mining Process: Combines previous block's hash, Merkle root of new transactions, a nonce, and a timestamp.
Success Criterion: SHA(Merkle Root + Previous Block Hash + Timestamp + Nonce) < target
- Number of leading zeros indicates difficulty level

Longest Chain Rule & 51% Attack

51% Attack: Control over more than half of the computational power can result in a fake chain being accepted.
Prevention: Wait for 6 block confirmations before proceeding with transactions.

Summary of PoW Features

Challenging: Difficult to solve but easy to verify
Fairness: No shortcuts
Randomness: Ensures a decentralized and unpredictable process
Stability: Enables the stable operation of the blockchain with multiple-party participation

Review

Transaction model

Each transaction omits the remaining part of itself. For example, in the second block, there should be the remaining 3.5 BTC from A to himself.

The Hash Pointer of each transfer party points to all previous sources of income, which can avoid double-spending attacks.

Each transfer party must sign the transaction.

UTXO Model

Alice forwarded it to bob. Whose is the first PubkeyHash?
The second <sig><PubKey>, whose PubkeyHash belongs to it?
What's in <sig>?

In Bitcoin, a common script pattern for a standard Pay-to-PubkeyHash (or P2PKH) transaction is as follows:

Lock script (ScriptPubKey):OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
Unlock script (ScriptSig):<Sig> <PubKey>

Here<PubkeyHash> and <Sig>, <PubKey> are placeholders in different scripts. They are used in actual transactions. will be replaced by actual data.

For the first question:

in OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG <PubkeyHash> is Bob’s public key hash. Alice wants to send Bitcoin to Bob, so this script locks the output belonging to Bob.

For the second question:

Zaikaiton script <Sig> <PubKey> Medium:

<Sig>is the result of Bob signing this transaction with his private key.
<PubKey>is Bob's public key.
<PubkeyHash>Still a hash of Bob's public key.

In this way, when the two scripts are merged and executed, they will first calculate a public key hash using <PubKey> and then check whether this calculated public key hash matches the lock <PubkeyHash> in the script are equal. If equal, and <Sig> is a valid signature for the transaction, then the output is considered valid and is unlocked and can be spent.