How Blocks Link Chronologically

In standard computing, databases use timestamps to put events in chronological order. However, in a decentralized, peer-to-peer network, timestamps cannot be trusted. Nodes are spread across different timezones, and malicious actors can easily back-date or forward-date their system clocks to lie about when a transaction occurred.

To solve this, Bitcoin does not rely on wall clocks. Instead, it uses cryptographic linking to establish an unforgeable, chronological order of time.

---

🔗 The Parent-Child Cryptographic Link

In Bitcoin, every block is physically bound to the block that came before it. This is achieved by embedding the unique hash of the previous block's header inside the new block's header.

 [ Block 1 Header ] ──────┐
 [ Transaction List]      │
                          ▼ (Double SHA-256)
                    [ Block 1 Hash ]
                          │
                          ▼
 ┌────────────────────────┴────────────────────────┐
 │                [ Block 2 Header ]               │
 │  - Version                                      │
 │  - Previous Block Hash: [ Block 1 Hash ] ◄──────┼─── (The Link)
 │  - Merkle Root                                  │
 │  - Timestamp, Difficulty Target, Nonce          │
 └────────────────────────┬────────────────────────┘
                          ▼ (Double SHA-256)
                    [ Block 2 Hash ]

Let's break down the mathematical sequence: 1. Block 1 is mined: Miners solve the Proof of Work for Block 1. Running its header through double SHA-256 produces its unique identity hash: 00000000000000000003b... 2. Constructing Block 2: When miners construct the candidate template for Block 2, they copy that exact hash and write it into the Previous Block Hash field inside Block 2’s header. 3. Hashing Block 2: When miners solve the Proof of Work for Block 2, the hash they produce is a mathematical function of Block 2's header—which now physically includes the hash of Block 1.

This creates a rigid, parent-child relationship. Block 2 cannot exist without referencing Block 1.

---

🦋 The Cascading Butterfly Effect (Why History is Locked)

This cryptographic chaining is what makes the blockchain tamper-evident and secure. If you change a single character of historical data, the entire chain ahead of it collapses.

Imagine an attacker attempts to alter a transaction in Block 100 to steal coins. Here is what happens:

Step 1: Attacker modifies transaction in Block 100.
                     │
                     ▼
Step 2: Merkle Root of Block 100 changes.
                     │
                     ▼
Step 3: Block 100 Header Hash changes completely (e.g. from 0000...a3 to 0000...9f).
                     │
                     ▼
Step 4: Block 101's header (which contains 'Prev Hash: 0000...a3') is now invalid.
                     │
                     ▼
Step 5: The link is broken! Every block from Block 101 to the present is orphaned.

Because block headers are cryptographically connected, changing a block in the past alters its hash, which breaks the link to the next block, which breaks the hash of the next block, cascading all the way to the present tip of the chain.

To make the network accept their altered transaction, the attacker would have to: 1. Re-solve the Proof of Work for Block 100. 2. Re-solve the Proof of Work for Block 101. 3. Re-solve every block all the way to the latest block. 4. Do this fast enough to catch up and overtake the active chain being mined by the honest network.

Because this requires more computational power than the rest of the entire planet combined, the history of the ledger is physically and mathematically locked in place.