Unit 4 - Notes
CSC203
Unit 4: Bitcoin Basics
1. The Bitcoin Blockchain
The Bitcoin blockchain is a decentralized, distributed ledger technology that records all transactions across a network of computers (nodes). It was introduced by Satoshi Nakamoto in 2008.
1.1 Architecture and Data Structure
Bitcoin uses a linked-list data structure where ordered batches of transactions (blocks) are linked together using cryptography.
- The Chain: Each block contains the cryptographic hash of the previous block, creating an immutable chain. If data in Block is changed, its hash changes, breaking the link to Block .
- The Ledger: Bitcoin does not store balances (e.g., "Alice has 5 BTC"). Instead, it stores transactions using the UTXO (Unspent Transaction Output) model.
1.2 Block Structure
A Bitcoin block consists of two main parts: the Block Header (metadata) and the Block Body (transactions).
A. Block Header (80 Bytes)
The header is the only part of the block that is hashed during mining. It contains:
- Version: Indicates which set of block validation rules to follow.
- Previous Block Hash: A 256-bit hash connecting to the previous block (parent).
- Merkle Root: A single hash representing all transactions in the block.
- Timestamp: Current time (seconds since Unix Epoch).
- Difficulty Target (nBits): The complexity required to mine the block.
- Nonce: A 32-bit variable counter used in Proof of Work.
B. Block Body
Contains the raw transaction data. The first transaction is always the Coinbase Transaction, which creates new Bitcoin and pays the miner the block reward and transaction fees.
1.3 The Merkle Tree
To ensure data integrity efficiently, transactions are hashed in pairs until a single "Root Hash" remains. This allows a node to verify a specific transaction is included in a block without downloading the entire block (SPV - Simplified Payment Verification).

2. Challenges and Solutions in Bitcoin
While Bitcoin pioneered decentralized currency, it faces specific technical hurdles.
2.1 Scalability
- The Problem: Bitcoin has a block size limit (originally 1MB) and a block time of ~10 minutes. This limits throughput to approximately 4–7 transactions per second (TPS).
- Solutions:
- Segregated Witness (SegWit): An update that separates signature data (witness) from transaction data, effectively increasing block capacity.
- The Lightning Network: A Layer-2 solution allowing off-chain payment channels. Only the opening and closing channel balances are recorded on the main blockchain, allowing instant, low-fee micropayments.
2.2 Privacy
- The Problem: Bitcoin is pseudonymous, not anonymous. All transaction histories are public. If a real-world identity is linked to a public address, the user's financial history is exposed.
- Solutions:
- CoinJoins: A strategy where multiple users combine their transactions into a single large transaction to obscure the trail of funds.
- Address Rotation: Wallets automatically generating new addresses for every change output.
2.3 Consensus Attacks
- The Problem: 51% Attack. If a single entity controls more than 50% of the network's hash rate, they can double-spend coins and prevent transaction confirmations.
- Solutions: The sheer amount of electricity and hardware required to attack Bitcoin makes it economically irrational (the cost to attack exceeds the potential gain).
3. Consensus Mechanism: Proof of Work (PoW)
Proof of Work is the consensus algorithm used by Bitcoin to secure the ledger and issue new coins. It solves the Byzantine Generals Problem in an open network.
3.1 The Mining Process
Mining is a probabilistic competition to find a hash that satisfies a specific condition.
- Transaction Aggregation: Miners collect pending transactions from the "Mempool."
- Block Construction: They construct a candidate block.
- The Puzzle (Hashing):
- The miner takes the Block Header and applies the SHA-256 hash function twice:
SHA256(SHA256(Block Header)). - The result must be less than or equal to the current Target (determined by Difficulty).
- The miner takes the Block Header and applies the SHA-256 hash function twice:
- The Nonce: Since the header data is fixed, the miner changes the Nonce (number used once) and re-hashes. They repeat this millions of times per second.
- Verification: When a miner finds a valid hash (one with enough leading zeros), they broadcast the block. Other nodes verify the hash independently.
3.2 Difficulty Adjustment
Every 2,016 blocks (approx. 2 weeks), the network adjusts the difficulty target to ensure the average block time remains 10 minutes, regardless of the total hash rate of the network.

4. Proof of Stake (PoS)
Proof of Stake is the primary alternative to PoW, utilized by Ethereum (post-Merge) and other modern chains to address energy concerns.
4.1 Concept
Instead of physical miners using hardware/electricity, Validators lock up (stake) native tokens as a security deposit.
- Selection: The protocol selects a validator to propose the next block based on the amount staked and the duration (coin-age).
- Validation: Other validators attest to the validity of the block.
- Incentive: Validators earn transaction fees/rewards.
- Penalty (Slashing): If a validator acts maliciously (e.g., validating two blocks at the same height), their staked coins are destroyed ("slashed").
4.2 Comparison: PoW vs. PoS
| Feature | Proof of Work (Bitcoin) | Proof of Stake (Ethereum, Cardano) |
|---|---|---|
| Resource | Computational Power (Electricity) | Economic Value (Staked Coins) |
| Attack Cost | Buying hardware + Energy | Buying 51% of total coin supply |
| Energy | Extremely High | Very Low (>99% less than PoW) |
| Centralization | Risk of Mining Pools | Risk of "Whales" (Rich get richer) |

5. Alternatives to Bitcoin Consensus
Beyond standard PoW and PoS, other mechanisms exist to trade off between decentralization, scalability, and security.
5.1 Delegated Proof of Stake (DPoS)
- Used by EOS, Tron.
- Token holders vote for a limited number of "Super Representatives" or "Delegates" (e.g., 21 nodes).
- Only these elected nodes validate blocks.
- Pros: extremely high throughput (TPS).
- Cons: More centralized; looks like a representative democracy.
5.2 Proof of Authority (PoA)
- Used in private/consortium blockchains (e.g., VeChain, testnets).
- Validators are identified, reputable entities (not anonymous).
- Identity is the stake.
- Pros: Fast, no mining required.
- Cons: Censorship resistance is low; requires trust in authorities.
5.3 Practical Byzantine Fault Tolerance (PBFT)
- Used by Hyperledger Fabric.
- Nodes communicate through multiple rounds of voting to reach consensus.
- Can tolerate up to 33% malicious nodes ().
- Pros: Finality is instant (no forks).
- Cons: High communication overhead; does not scale well to large numbers of nodes.
6. Bitcoin Scripting Language
Bitcoin does not use a typical programming language like Python or C++. It uses Script, a Forth-like, stack-based, reverse-polish notation language.
6.1 Characteristics of Script
- Stack-Based: Data is pushed onto a stack and operations (Opcodes) pop items off the stack, process them, and push results back.
- Not Turing Complete: It lacks loops (no
whileorforloops). This prevents infinite loops, protecting the network from DoS attacks. - Stateless: The script evaluates strictly based on information in the transaction itself.
6.2 Common Opcodes
OP_DUP: Duplicates the top item on the stack.OP_HASH160: Hashes the top item twice (SHA-256 then RIPEMD-160).OP_EQUALVERIFY: Checks if top two items are equal; fails transaction if not.OP_CHECKSIG: Verifies that a signature matches a public key.
6.3 Standard Transaction Types
Pay-to-Public-Key-Hash (P2PKH)
This is the most common Bitcoin transaction type.
The Locking Script (ScriptPubKey):
Placed on the Output of a transaction (UTXO).
OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
The Unlocking Script (ScriptSig):
Provided by the spender in the Input.
<Signature> <PublicKey>
Execution Process:
When the scripts are combined and executed:
- Push Data: Signature and Public Key are pushed to the stack.
- OP_DUP: The Public Key is duplicated.
- OP_HASH160: The duplicate key is hashed.
- OP_EQUALVERIFY: The hash is compared to the
<PubKeyHash>in the locking script. If they match, they are removed. - OP_CHECKSIG: Checks the signature against the original Public Key. If valid, the stack returns
TRUE, and the transaction is authorized.
