Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

UNIT 3
Blockchain Technology
Comprehensive Study Notes

Topics Covered: Properties of Hash Functions | Merkle Trees | Digital Signatures

Cryptographic Hash Functions | Blocks & Block Headers | Asymmetric Cryptography | Chain Forks

References:
[1] Imran Bashir, Mastering Blockchain, 2nd ed., Packt Publication, 2018
[2] Lorne Lantz & Daniel Cawrey, Mastering Blockchain, 1st ed., O'Reilly Publication, 2020
[3] Chris Dannen, Introducing Ethereum and Solidity, 1st ed., Apress Publication, 2017

Blockchain Technology Notes | Page 1 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

1. Properties of Hash Functions

Reference: [1] Bashir, Ch-4 (Pg 184-204)

A hash function is a mathematical algorithm that takes an input (or 'message') of arbitrary size and produces a
fixed-size output called a hash, digest, or fingerprint. Hash functions are foundational to blockchain technology
and cryptography.

1.1 Definition and Overview

A cryptographic hash function H takes an input m of any length and produces a fixed-length output: H(m) = h.
The resulting hash h is a compact digital representation of the input. Even a tiny change in input produces a
completely different hash, making hash functions extremely sensitive to data changes.

1.2 Essential Properties of Cryptographic Hash Functions

Core Properties of Hash Functions

1. Pre-image Resistance (One-way Property)

2. Second Pre-image Resistance (Weak Collision Resistance)
3. Collision Resistance (Strong Collision Resistance)
4. Determinism
5. Avalanche Effect
6. Efficiency
7. Pseudorandomness

1.2.1 Pre-image Resistance (One-Way Property)

Given a hash h, it should be computationally infeasible to find any input m such that H(m) = h. This ensures that
hash functions act as one-way trapdoors — easy to compute in one direction but practically impossible to
reverse. This property is critical for password hashing, where stored password hashes cannot be reversed to
obtain the original password.
[1] Bashir, Ch-4 Pg 184-186

1.2.2 Second Pre-image Resistance (Weak Collision Resistance)

Given a specific input m1, it should be computationally infeasible to find a different input m2 (where m1 != m2)
such that H(m1) = H(m2). This protects the integrity of data — an attacker cannot substitute a document with a
forged one that produces the same hash.

1.2.3 Collision Resistance (Strong Collision Resistance)

It should be computationally infeasible to find any two distinct inputs m1 and m2 such that H(m1) = H(m2). This
is a stronger requirement than second pre-image resistance because the attacker has freedom to choose both

Blockchain Technology Notes | Page 2 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

inputs. Collisions are theoretically possible due to the pigeonhole principle (infinite inputs mapped to finite
outputs), but should be practically impossible to find.
[1] Bashir, Ch-4 Pg 186-188

1.2.4 Determinism
The same input must always produce the same output hash. For a given message m, H(m) must always return
the same hash h, regardless of when or where the function is executed. This property is essential for verification
— a document can be authenticated by recomputing and comparing its hash.

1.2.5 Avalanche Effect

A small change in the input (even a single bit flip) should produce a drastically different output hash. Ideally,
approximately 50% of output bits should change when any single input bit is flipped. This property ensures that
similar inputs produce completely different, unpredictable hashes, preventing pattern analysis.
[1] Bashir, Ch-4 Pg 189-190

1.2.6 Efficiency
A hash function should be computationally efficient — easy and fast to compute for any given input. Unlike
encryption algorithms, hash functions are not designed to be slow; they must process large volumes of data
quickly, especially in blockchain systems where millions of transactions need to be hashed.

1.2.7 Pseudorandomness
The output of a hash function should appear random and uniformly distributed. There should be no discernible
pattern between the input and output. Hash outputs should pass statistical randomness tests, appearing as
though they were generated by a random process.

1.3 Common Hash Algorithms

Algorithm Description & Usage

SHA-256 Secure Hash Algorithm 256-bit. Used in Bitcoin for mining (Proof of
Work) and transaction IDs. Produces a 256-bit (32 byte) output.
SHA-3 (Keccak) Used in Ethereum. Winner of NIST hash competition. Produces variable-
length outputs (224, 256, 384, 512 bits).
RIPEMD-160 Race Integrity Primitives Evaluation Message Digest. Used in Bitcoin for
address generation alongside SHA-256. Produces 160-bit output.
MD5 Message Digest 5. Produces 128-bit hash. Now considered
cryptographically broken; not used in modern blockchains.
SHA-1 Secure Hash Algorithm 1. Produces 160-bit hash. Deprecated due to
discovered vulnerabilities.

[1] Bashir, Ch-4 Pg 190-200 | [2] Lantz & Cawrey, Ch-2 Pg 33-38

1.4 Applications of Hash Functions in Blockchain

• Transaction IDs: Each transaction is identified by its hash (TXID/TXHASH)
Blockchain Technology Notes | Page 3 of 17
Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

• Block Identification: Each block is identified by its block header hash

• Merkle Trees: Hash functions build the Merkle tree structure for efficient verification
• Mining / Proof of Work: Miners must find an input (nonce) that produces a hash meeting difficulty
target
• Address Generation: Wallet addresses are derived from hashing public keys
• Digital Signatures: Hash of message is signed rather than the message itself
• Data Integrity: Any tampered data produces a different hash, immediately detectable

Blockchain Technology Notes | Page 4 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

2. Merkle Trees
Reference: [1] Bashir, Ch-4 (Pg 184-204)

A Merkle tree (also called a hash tree) is a tree data structure where each leaf node contains the cryptographic
hash of a data block, and each non-leaf (parent) node contains the hash of its child nodes. Named after computer
scientist Ralph Merkle who patented the concept in 1979.

2.1 Structure of a Merkle Tree

A Merkle tree is constructed bottom-up:
• Leaf Nodes: The bottom level contains hashes of individual data blocks (transactions in blockchain)
• Intermediate Nodes: Each parent node is computed by hashing the concatenation of its two children:
Parent = H(Left_Child + Right_Child)
• Root Node (Merkle Root): The single hash at the top that represents the entire dataset. Any change in
any transaction changes the Merkle root.
• Tree Shape: Binary tree structure (each parent has exactly two children). If the number of transactions
is odd, the last transaction hash is duplicated.

Merkle Tree Construction Example (4 Transactions)

Level 0 (Leaves): Hash(Tx1), Hash(Tx2), Hash(Tx3), Hash(Tx4)

Level 1: Hash(H1 + H2) = H12, Hash(H3 + H4) = H34
Level 2 (Root): Hash(H12 + H34) = Merkle Root
Any change to any Tx propagates up and changes the Merkle Root

[1] Bashir, Ch-4 Pg 195-200

2.2 Properties of Merkle Trees

• Tamper Detection: Changing any transaction data changes its leaf hash, which propagates to change
all parent hashes up to the root
• Efficient Verification: To verify a transaction, only O(log n) hashes need to be checked (the path from
leaf to root)
• Space Efficiency: Only the root hash needs to be stored for integrity verification
• Independent of Order: Position in tree is important; reordering transactions changes the tree

2.3 Merkle Proofs (Simplified Payment Verification - SPV)

Merkle proofs allow a lightweight client (SPV node) to verify that a specific transaction is included in a block
without downloading the entire blockchain. The proof consists of the hashes of sibling nodes along the path
from the transaction's leaf node to the root.

• SPV clients only download block headers (containing Merkle root)

Blockchain Technology Notes | Page 5 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

• To verify transaction Tx2, provide: Hash(Tx1), Hash(H3+H4)

• Client recomputes: H(H(Tx1)+H(Tx2)) then H(result + H34) and compares to stored Merkle Root
• Proof size is O(log n) — for 1 million transactions, only ~20 hashes needed
[1] Bashir, Ch-4 Pg 200-204

2.4 Merkle Trees in Bitcoin vs Ethereum

Feature Details

Bitcoin Merkle Tree Simple binary Merkle tree. Each block header contains one Merkle root
representing all transactions in the block.
Ethereum Merkle Patricia Ethereum uses a more complex modified Merkle Patricia Tree (Trie)
Tree structure. Three separate tries exist: Transaction Trie, Receipt Trie, and
State Trie.
State Root Ethereum's state trie enables verification of account balances and
contract state at any block height.
Efficiency Both systems allow SPV (light client) verification without full blockchain
download.

Blockchain Technology Notes | Page 6 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

3. Digital Signatures
Reference: [1] Bashir, Ch-4 (Pg 184-204)

A digital signature is a cryptographic mechanism that provides authentication, integrity, and non-repudiation
for digital messages or documents. Digital signatures are the blockchain equivalent of handwritten signatures
but are far more secure due to mathematical underpinnings.

3.1 Properties of Digital Signatures

• Authentication: Proves the message came from the stated sender
• Integrity: Guarantees the message has not been altered since signing
• Non-repudiation: Signer cannot deny having signed the message
• Unforgeable: Only the holder of the private key can produce a valid signature

3.2 Digital Signature Process

3.2.1 Signing Process
The sender (Alice) creates a digital signature using these steps:
• Step 1: Compute the hash of the message: h = H(message)
• Step 2: Encrypt the hash with Alice's private key: signature = Encrypt(h, private_key)
• Step 3: Send the message along with the signature

3.2.2 Verification Process

The receiver (Bob) verifies the signature:
• Step 1: Decrypt the signature using Alice's public key: h' = Decrypt(signature, public_key)
• Step 2: Independently compute the hash of the received message: h = H(message)
• Step 3: Compare h and h'. If h == h', the signature is valid — message is authentic and unaltered
[1] Bashir, Ch-4 Pg 184-190

3.3 ECDSA — Elliptic Curve Digital Signature Algorithm

Both Bitcoin and Ethereum use ECDSA for digital signatures, specifically over the secp256k1 elliptic curve. ECDSA
provides the same security as RSA but with much smaller key sizes.

ECDSA Parameter Details

Curve secp256k1 (Koblitz curve: y² = x³ + 7 over a finite field)

Private Key 256-bit randomly generated number. Must be kept secret.
Public Key Computed from private key using elliptic curve multiplication: Pub = priv
* G (G = generator point)
Signature Components Signature consists of two 256-bit integers (r, s)

Blockchain Technology Notes | Page 7 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

Security Breaking ECDSA requires solving the Elliptic Curve Discrete Logarithm
Problem (ECDLP) — computationally infeasible
Key Size Advantage 256-bit ECDSA key offers same security as 3072-bit RSA key

[1] Bashir, Ch-4 Pg 154-165 | [2] Lantz & Cawrey, Ch-5 Pg 269-275

3.4 Digital Signatures in Blockchain Transactions

• Transaction Authorization: Spending cryptocurrency requires a valid digital signature from the owner's
private key
• Input Scripts (Bitcoin): scriptSig contains the signature and public key
• ECDSA in Ethereum: Every transaction is signed with the sender's private key; signature contains v, r, s
components
• Multi-signature: Multiple signatures required to authorize a transaction (M-of-N multisig)
• Schnorr Signatures: Modern alternative being adopted (Bitcoin Taproot); allows signature aggregation
for efficiency

Blockchain Technology Notes | Page 8 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

4. Cryptographic Hash Functions, Hashes, Blocks, Block Headers

Reference: [2] Lantz & Cawrey, Ch-2 (Pg 33-38) | [1] Bashir, Ch-5 (Pg 269-275)

4.1 Cryptographic Hash Functions (Deep Dive)

Cryptographic hash functions are a specialized subset of hash functions designed to be practically irreversible
and collision-resistant. Unlike general-purpose hash functions used in data structures, cryptographic hash
functions are designed to withstand deliberate adversarial attacks.

4.1.1 SHA-256 (Bitcoin's Primary Hash Function)

SHA-256 (Secure Hash Algorithm 256-bit) is a member of the SHA-2 family designed by the NSA. It is the primary
hash function in Bitcoin, used for both mining (Proof of Work) and in constructing transaction identifiers.
• Input: Message of any length
• Output: 256-bit (32-byte) hash — represented as a 64-character hexadecimal string
• Block size: 512 bits (64 bytes)
• Word size: 32 bits
• Rounds: 64 rounds of compression
• Bitcoin uses SHA-256 twice (double-SHA-256) for block hashing: H = SHA256(SHA256(data))
[2] Lantz & Cawrey, Ch-2 Pg 33-38

4.1.2 Keccak-256 (Ethereum's Hash Function)

Ethereum uses Keccak-256 (a variant of SHA-3) for hashing. Keccak was the winning submission in NIST's SHA-3
competition. Note: Ethereum's Keccak-256 is slightly different from the standardized SHA-3-256.
• Used in Ethereum for transaction hashing, state trie hashing, address generation
• Based on sponge construction (different from Merkle-Damgard used in SHA-2)
• More resistant to length extension attacks compared to SHA-256
[1] Bashir, Ch-4 Pg 192-195

4.1.3 RIPEMD-160
RIPEMD-160 (RACE Integrity Primitives Evaluation Message Digest) produces a 160-bit hash. Bitcoin uses it in
combination with SHA-256 to generate wallet addresses:
• Bitcoin Address Generation: address = RIPEMD160(SHA256(public_key))
• The combination provides both the security of SHA-256 and shorter address length of RIPEMD-160
• Final Bitcoin address also includes version byte, checksum, and Base58Check encoding

4.2 Blocks in Blockchain

A block is the fundamental data structure in a blockchain. Each block is a container that bundles a set of
transactions together, along with metadata, and is cryptographically linked to the previous block, forming the
chain.

Blockchain Technology Notes | Page 9 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

4.2.1 Block Structure

Block Component Description

Block Header 80-byte metadata structure containing version, previous block hash,
Merkle root, timestamp, difficulty target, and nonce
Transaction Counter Number of transactions included in the block (varint format)
Transaction List All transactions included in the block. First transaction is always the
coinbase transaction.
Coinbase Transaction Special first transaction that rewards the miner with newly created coins
+ transaction fees. Has no inputs.
Block Size Bitcoin: max 1MB (SegWit: up to ~4MB weight). Ethereum: gas limit
determines block size.
Block Hash SHA256(SHA256(block_header)) — uniquely identifies the block

[1] Bashir, Ch-5 Pg 269-275 | [2] Lantz & Cawrey, Ch-5 Pg 269-275

4.3 Block Headers

The block header is the most critical part of a block. It is an 80-byte structure that contains all the information
needed to identify and validate a block. The block hash is computed from the block header only.

Bitcoin Block Header Fields (80 bytes total)

1. Version (4 bytes): Block version number indicating protocol rules

2. Previous Block Hash (32 bytes): SHA256(SHA256()) of previous block header — creates the chain
3. Merkle Root (32 bytes): Root hash of the Merkle tree of all transactions in this block
4. Timestamp (4 bytes): Unix epoch time when block was created (seconds since Jan 1, 1970)
5. Difficulty Target / nBits (4 bytes): Compact encoding of the current mining difficulty target
6. Nonce (4 bytes): 32-bit number that miners iterate through to find a valid block hash

4.3.1 Previous Block Hash — The Chain

The inclusion of the previous block hash in each block header is what creates the blockchain. Changing any
transaction in a past block changes its Merkle root, which changes the block header hash, which breaks the link
with the next block. Every subsequent block must also be recomputed, making blockchain immutable in practice.
[1] Bashir, Ch-5 Pg 270-272

4.3.2 Difficulty Target

The difficulty target specifies how small the block hash must be for the block to be valid. It is stored in a compact
4-byte format called nBits. The actual target is a 256-bit number; a valid block hash must be less than or equal
to this target. The network adjusts difficulty approximately every 2016 blocks (Bitcoin) to maintain a 10-minute
average block time.

Blockchain Technology Notes | Page 10 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

• High difficulty = very small target = hash must have many leading zeros
• Example: 0000000000000000000abc... (many leading zeros required)
• Bitcoin adjusts difficulty every 2016 blocks (~2 weeks)
• Ethereum uses GHOST protocol for dynamic difficulty adjustment

4.3.3 Nonce
The nonce (Number Used Once) is the field that miners vary when mining. Miners repeatedly hash the block
header with different nonce values, trying to find a hash that meets the difficulty target. Since the nonce is only
4 bytes (2^32 possible values ≈ 4 billion), miners also modify the extraNonce field in the coinbase transaction
when the nonce space is exhausted.
[1] Bashir, Ch-5 Pg 272-275

Blockchain Technology Notes | Page 11 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

5. Asymmetric Cryptography
Reference: [1] Bashir, Ch-4 (Pg 154-161)

Asymmetric cryptography (also called public-key cryptography) uses a pair of mathematically related keys: a
public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be
decrypted with the corresponding private key, and vice versa.

5.1 Key Concepts

• Key Pair: Public key + Private key. Mathematically linked but computationally infeasible to derive one
from the other
• Public Key: Shared openly with everyone. Used for encryption and signature verification
• Private Key: Kept strictly secret. Used for decryption and signing
• Trapdoor Function: One-way mathematical function easy to compute but hard to reverse without
special information (the private key)
[1] Bashir, Ch-4 Pg 154-158

5.2 Major Asymmetric Algorithms

Algorithm Description & Blockchain Usage

RSA Based on difficulty of factoring large integers. Key sizes: 2048-4096 bits.
Not used in major blockchains due to large key size.
ECDSA (secp256k1) Elliptic Curve Digital Signature Algorithm. Used in Bitcoin and Ethereum.
256-bit key offers security equivalent to 3072-bit RSA.
EdDSA (Ed25519) Edwards-curve Digital Signature Algorithm. Used in newer blockchains
(Cardano, Solana, Stellar). Faster and more secure than ECDSA.
Diffie-Hellman (ECDH) Key exchange protocol. Used for establishing shared secrets between
parties in blockchain communication layers.
Schnorr Signatures More efficient than ECDSA; enables signature aggregation. Adopted in
Bitcoin via Taproot upgrade (2021).

5.3 Elliptic Curve Cryptography (ECC)

ECC is based on the algebraic structure of elliptic curves over finite fields. The security relies on the Elliptic Curve
Discrete Logarithm Problem (ECDLP): given points P and Q on a curve where Q = k*P, it is computationally
infeasible to find k.

5.3.1 The secp256k1 Curve

Bitcoin and Ethereum use the secp256k1 elliptic curve, defined by the equation: y² = x³ + 7 (mod p), where p is
a large 256-bit prime number.

Blockchain Technology Notes | Page 12 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

• Generator Point G: A fixed, publicly known point on the curve

• Private Key (k): A randomly chosen integer in range [1, n-1] where n is the curve order
• Public Key (K): Computed as K = k * G (elliptic curve point multiplication)
• One-Way: Easy to compute K from k, but practically impossible to derive k from K
[1] Bashir, Ch-4 Pg 158-164

5.3.2 Key Generation in Bitcoin/Ethereum

The process of generating a Bitcoin/Ethereum address from a private key involves multiple steps of hashing and
encoding:
• Step 1: Generate a random 256-bit private key (must be in valid range)
• Step 2: Compute public key using ECDSA: PublicKey = PrivateKey * G
• Step 3 (Bitcoin): SHA256 + RIPEMD160 hash of public key, add version byte, compute checksum,
Base58Check encode
• Step 3 (Ethereum): Keccak-256 hash of public key, take last 20 bytes, prepend 0x
• Result: Bitcoin address (~34 chars, Base58Check) or Ethereum address (42 chars hex)

5.4 Encryption vs. Signing — Two Uses of Asymmetric Cryptography

Use Case How It Works

Encryption (Confidentiality) Sender encrypts with recipient's PUBLIC key. Only recipient can decrypt
using their PRIVATE key. Ensures only intended recipient can read the
message.
Digital Signatures Sender signs with their own PRIVATE key. Anyone can verify using
(Authentication) sender's PUBLIC key. Proves message came from sender and was not
altered.
Blockchain Usage Blockchain primarily uses signing (not encryption). Transactions are
signed with private keys to prove ownership. The blockchain ledger is
public, not encrypted.

[1] Bashir, Ch-4 Pg 154-165

5.5 HD Wallets and Key Derivation

Hierarchical Deterministic (HD) wallets, defined in BIP-32, allow deriving a tree of key pairs from a single master
seed. This eliminates the need to back up every individual key separately.
• Master Seed: Random entropy (128-256 bits) from which all keys are derived
• BIP-39: Defines mnemonic phrases (12-24 words) as human-readable representation of seed
• BIP-44: Multi-account hierarchy standard for HD wallets
• Child Key Derivation: Uses HMAC-SHA512 of parent key + index to derive child keys
• Extended Keys: xpub (extended public key) allows watch-only wallets; xpriv for signing

Blockchain Technology Notes | Page 13 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

6. Chain Forks
Reference: [2] Lantz & Cawrey, Ch-3 (Pg 59-70) | [3] Dannen, Ch-6 (Pg 123-124)

A fork in a blockchain occurs when the network diverges into two or more competing chains. Forks are a natural
consequence of the decentralized nature of blockchain networks and can occur unintentionally or as deliberate
protocol upgrades.

6.1 Why Forks Occur

• Software Updates: Protocol rule changes that not all nodes adopt simultaneously
• Accidental Forks: Two miners simultaneously find valid blocks — temporary fork until network
consensus selects one chain
• Contentious Upgrades: Community disagreement on protocol direction leads to permanent chain
splits
• Bug Fixes: Emergency protocol changes to address critical vulnerabilities
• Network Partitions: Temporary network splits cause separate chains to develop independently
[2] Lantz & Cawrey, Ch-3 Pg 59-62

6.2 Types of Forks

6.2.1 Soft Fork

A soft fork is a backward-compatible upgrade to blockchain protocol rules. New rules are more restrictive (a
strict subset of the old rules). Old nodes still accept blocks from new nodes as valid, although they may not
understand all new features.

Soft Fork Characteristics

Backward Compatible: Old nodes can still participate (though with reduced functionality)
Only miners/new nodes need to upgrade to enforce new rules
New blocks are valid under old rules (but old blocks may not be valid under new rules)
Examples: Bitcoin SegWit (BIP-141), P2SH (BIP-16), CSV (BIP-68)
Risk: If majority of hash power does not upgrade, new rules are not enforced

[2] Lantz & Cawrey, Ch-3 Pg 62-65

6.2.2 Hard Fork

A hard fork is a non-backward-compatible protocol upgrade. New rules are not a subset of old rules — blocks
valid under new rules may be invalid under old rules. Hard forks require all nodes to upgrade or the chain
permanently splits.

Blockchain Technology Notes | Page 14 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

Hard Fork Characteristics

NOT Backward Compatible: Old nodes reject new blocks as invalid

All nodes must upgrade — those that don't follow old chain
If community is divided, results in two permanent separate blockchains
Each chain has its own token (e.g., ETH and ETC after Ethereum fork)
Examples: Bitcoin Cash (BCH) from BTC, Ethereum Classic (ETC) from ETH
Planned Hard Forks: Ethereum's transition through Frontier, Homestead, Metropolis, Constantinople

[2] Lantz & Cawrey, Ch-3 Pg 65-68 | [3] Dannen, Ch-6 Pg 123-124

6.2.3 Accidental / Temporary Fork

When two miners discover valid blocks at approximately the same time, each propagates their block to the
network. Different nodes may receive different blocks first, causing a temporary fork. The network resolves this
using the longest chain rule (Bitcoin) or heaviest chain (GHOST protocol, Ethereum).
• Duration: Lasts until next block is found, extending one of the competing chains
• Resolution: Nodes switch to longer/heavier chain; the shorter chain becomes orphaned
• Orphan Blocks: Valid blocks that did not make it into the main chain
• Stale Blocks (Ethereum): Similar to orphan blocks; Ethereum calls them 'uncle blocks' and partially
rewards them
[2] Lantz & Cawrey, Ch-3 Pg 59-62

6.3 Famous Historical Forks

Fork Event Details

Bitcoin Cash (BCH) — Aug Hard fork from Bitcoin. BCH increased block size to 8MB (later 32MB) to
2017 improve transaction throughput. Result of disagreement over Bitcoin
scaling.
Ethereum Classic (ETC) — Jul Hard fork following the DAO hack. Ethereum Foundation performed a
2016 contentious hard fork to reverse the hack ($60M lost). Dissenters
maintained the original chain as Ethereum Classic.
Bitcoin SV (BSV) — Nov 2018 Hard fork from Bitcoin Cash. Craig Wright's faction increased block size
to 128MB. Promoted as 'Satoshi's Vision.'
Bitcoin SegWit (Soft Fork) — Segregated Witness upgrade separated signature data from transaction
Aug 2017 data. Effectively increased capacity and fixed transaction malleability.
Ethereum The DAO Fork — Controversial emergency hard fork at block 1,920,000 to return DAO
2016 funds. Led to ideological split in Ethereum community.

[2] Lantz & Cawrey, Ch-3 Pg 59-70 | [3] Dannen, Ch-6 Pg 123-124

6.4 Fork Resolution Mechanisms

Blockchain Technology Notes | Page 15 of 17
Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

6.4.1 Nakamoto Consensus (Bitcoin — Longest Chain Rule)

Bitcoin uses the longest chain rule: when a fork occurs, nodes follow the chain with the most accumulated Proof
of Work (not simply the most blocks). Honest miners always extend the longest chain. An attacker would need
>50% of network hash power to rewrite history (51% attack).
[2] Lantz & Cawrey, Ch-3 Pg 65-67

6.4.2 GHOST Protocol (Ethereum)

Ethereum uses the Greedy Heaviest Observed Subtree (GHOST) protocol. Unlike Bitcoin, Ethereum gives partial
block rewards to uncle blocks (stale blocks that are close relatives of the canonical chain). This reduces the
disadvantage of small miners and allows faster block times (~12-15 seconds vs Bitcoin's 10 minutes) without
significantly increasing fork risk.
• Uncle blocks must be within 6 generations of the canonical chain
• Uncle block miners receive 7/8 of block reward
• Nephew block (includes uncle reference) receives 1/32 of block reward
• Limits uncle inclusion to 2 per block
[2] Lantz & Cawrey, Ch-3 Pg 67-70

6.5 51% Attack — The Fork Threat

A 51% attack occurs when a single entity gains majority control of a blockchain network's mining power. The
attacker can: mine a private fork, outpace the public chain, and broadcast the longer chain to rewrite recent
history.
• Double Spend: Attacker sends coins in a transaction, mines a private fork excluding that transaction,
then broadcasts the longer fork to invalidate the original transaction
• Transaction Censorship: Prevent specific transactions from being included
• Block Withholding: Mine blocks but not broadcast them, then release multiple at once
• Limitation: Cannot steal coins from others' wallets; cannot forge digital signatures; cannot change
total supply
• Cost: Extremely expensive on large networks like Bitcoin (requires billions in mining hardware +
electricity)
[2] Lantz & Cawrey, Ch-3 Pg 68-70

Blockchain Technology Notes | Page 16 of 17

Unit 3: Blockchain Technology | Study Notes [Ref: Bashir (2018), Lantz & Cawrey (2020), Dannen (2017)]

7. Summary and Quick Reference

Topic Key Points

Hash Functions One-way, deterministic, collision-resistant, avalanche effect. SHA-256

(Bitcoin), Keccak-256 (Ethereum).
Merkle Trees Binary hash tree. Efficient transaction verification (O log n). Merkle root
in block header. Enables SPV.
Digital Signatures ECDSA over secp256k1. Sign with private key; verify with public key.
Provides authentication, integrity, non-repudiation.
Block Structure Header (80 bytes) + Tx counter + Transaction list. Block hash =
SHA256(SHA256(header)).
Block Header Version, Prev Hash, Merkle Root, Timestamp, nBits (difficulty), Nonce.
Asymmetric Cryptography Public/private key pair. Private key → Public key (one-way via ECC). Used
for signing transactions.
Soft Fork Backward compatible. Old nodes accept new blocks. Less disruptive.
Example: SegWit.
Hard Fork Not backward compatible. Chain splits if not all nodes upgrade. Example:
BCH from BTC.
51% Attack Majority hash power can rewrite recent history, enable double-spends.
Cannot forge signatures or steal.

Blockchain Technology Notes | Page 17 of 17