How does the blockchain record transactions? Blocks, hashes, proof of work (2026)

The previous article covered the overall logic of Bitcoin's decentralized network, distributed ledger and consensus mechanism.

Now let's break it down a step further: what exactly is stored inside a block? What are miners actually "computing"? Why is a transaction hard to overturn after 6 confirmations?

These three questions are the key to understanding how the Bitcoin blockchain works.

This article opens up the "internal structure" of a Bitcoin block and explains hash algorithms, Merkle Trees and proof of work with everyday analogies. No cryptographic math derivations — just concepts and logic.

By the end you'll understand:

1. The internal structure of a Bitcoin block — what information is hidden in the block header;
2. The UTXO model — why Bitcoin doesn't record "balances," but "unspent outputs";
3. What a Merkle Tree is and why it's used to organize transactions;
4. How the SHA-256 hash forms the security foundation of Bitcoin;
5. What the proof-of-work (PoW) "math problem" actually is;
6. Why more confirmations make a transaction safer.

This article is a technical explainer and does not constitute investment advice.

It's recommended to read the previous article first: Why doesn't Bitcoin need banks? UTXO, nodes, PoW.

What's inside a Bitcoin block

A Bitcoin block can be split into two parts: the block header and the transaction list.

Block Header

It's only 80 bytes — tiny — but it contains all the core information needed to verify the whole block:

Field	Size	What it stores	Purpose
Version	4 bytes	The block format version	Compatibility marker
Previous block hash	32 bytes	The SHA-256 hash of the previous block	The key that chains blocks together
Merkle Root	32 bytes	The "collective fingerprint" of all transactions	Efficiently verify a transaction exists
Timestamp	4 bytes	The approximate time the block was created	Works with difficulty adjustment
Difficulty target	4 bytes	The difficulty value the network currently requires	Controls block production rate
Nonce	4 bytes	The number miners keep changing	The core of PoW mining

Transaction List

Below the block header is the transaction list — all the Bitcoin transfer records packed into this block.

A block usually contains hundreds to thousands of transactions.

Simple way to think about it:

Block header = the "page header" of this ledger page (page number, previous page summary, fingerprint of this page's content)

Transaction list = the "body" of this ledger page (the actual transfer records)

Block header in detail: how 80 bytes support the entire network

The block header is only 80 bytes, but its design is very clever. These six fields each do their own job:

Previous block hash: the soul of the chain structure

This field stores the result of the previous block's header being run through SHA-256 twice.

The significance: if someone changes a transaction 100 blocks ago, that block's hash changes → the "previous block hash" stored in the next block no longer matches → the next one also fails to match → all 100 blocks become invalid and need recomputing.

This is the essence of the "chain" — using hash pointers to lock down history.

Merkle Root: the "collective fingerprint" of transactions

The Merkle Root is the result of "compressing" all transactions in the current block into a single 32-byte hash.

Its purpose isn't tamper-resistance — it's to let anyone quickly verify "whether a certain transaction is in this block" without downloading the whole block.

The specific mechanism is explained in detail later.

Difficulty target: controlling the block-production rhythm

The difficulty target (bits) is a compressed-format number that determines the range below which a miner's hash must fall.

Difficulty isn't fixed — the Bitcoin network adjusts it automatically every 2016 blocks (about two weeks), aiming to keep the average block time stable at around 10 minutes.

If the past 2016 blocks were mined in only 9 days (hashrate too strong), the difficulty auto-adjusts upward. If they took 15 days (hashrate weaker), the difficulty drops.

This is a fully automated, self-regulating system that depends on no one's judgment — open a block explorer like Mempool.space and you can see the current difficulty and network hashrate moving in real time with the latest block production.

Nonce: the "answer" in the mining race

The Nonce is a 32-bit integer (0 to about 4.2 billion). A miner's job is to keep changing the nonce, run the block header through SHA-256 twice, and check whether the result is below the difficulty target.

Because SHA-256's output looks completely random, miners can only brute-force — try their luck.

The 4-byte nonce space (about 4.29 billion possibilities) can be exhausted instantly by modern ASIC miners. So miners don't only change the nonce — they also modify the extraNonce field in the coinbase transaction, reorder transactions, or fine-tune the timestamp. These operations all change the Merkle Root, giving a brand-new search space — effectively expanding the "lottery number pool" to near-infinity.

Key prerequisite concept: Bitcoin doesn't record "balances," only UTXOs

Before continuing with hashes and Merkle Trees, one key concept must be cleared up — many newcomers think Bitcoin maintains an "account balance" for each address like a bank does:

Wrong understanding:
Alice's account: 10 BTC → sends 2 BTC → balance 8 BTC
Bob's account:   0 BTC  → receives 2 BTC → balance 2 BTC

Bitcoin doesn't work like that. Bitcoin has no "account balance," only UTXOs (Unspent Transaction Outputs).

What is a UTXO

The most intuitive way to understand a UTXO is as a "banknote":

• Your wallet isn't "a single balance number" but several banknotes of different denominations
• Each banknote (UTXO) comes from a previous transfer and has a fixed denomination
• To pay 2 BTC, you need to bring out one or more banknotes totaling ≥ 2 BTC
• If you bring out a 5 BTC UTXO and pay 2 BTC, the remaining 3 BTC returns to your address as a change UTXO

A concrete example

Alice owns two UTXOs:
  UTXO-A: 3 BTC (from a transfer last month)
  UTXO-B: 1 BTC (from a transfer last week)

Alice wants to send Bob 2.5 BTC:

→ Transaction inputs:
  Spend UTXO-A (3 BTC)
  Spend UTXO-B (1 BTC)
  Total input: 4 BTC

→ Transaction outputs:
  Output 1: 2.5 BTC → Bob's address (payment)
  Output 2: 1.4 BTC → Alice's change address (4 - 2.5 - 0.1 fee)
  Total output: 3.9 BTC (0.1 BTC is the miner's fee)

UTXO-A and UTXO-B are fully spent (destroyed) in this transaction, while two new UTXOs are created — one to Bob, one as change to Alice. The old UTXOs no longer exist.

Why UTXO instead of an account-balance model

Comparison	UTXO model (Bitcoin)	Account-balance model (Ethereum)
Recording	Records a set of unspent "banknotes"	Records each address's balance number
Verification	Only checks whether the input UTXO is unspent	Checks whether the balance is sufficient
Parallel processing	Naturally supported — different UTXOs don't conflict	Transactions for the same address must queue
Privacy	Higher — can use a different address for change each time	All operations revolve around one address balance

The UTXO model is one of the fundamental design differences between Bitcoin and Ethereum. Understanding UTXO is the key to seeing why Bitcoin's transaction verification doesn't need to "check a balance" — it only needs to confirm the referenced UTXO hasn't been spent yet.

This also explains why the "transaction list" in a block isn't "Alice -10, Bob +10," but which UTXOs are referenced as inputs and which new UTXOs are created as outputs.

What a hash algorithm is, and why Bitcoin uses it

First, understand what a hash is

A hash function does this: takes input of any length and outputs a fixed-length "fingerprint."

For example, throw "Hello" into SHA-256 and you get a 64-character hexadecimal string. Throw the entire text of a long novel in, and you also get a 64-character string.

SHA-256 has three key properties:

Property	What it means	What it means for Bitcoin
One-way	Having the hash, you can't reverse-engineer the original input	No one can reverse a block hash to derive the block contents or nonce
Avalanche effect	Change the input by a tiny bit (even one punctuation mark) and the output changes completely	Tamper with one transaction → Merkle Root becomes totally different → block hash totally different → the chain breaks
Collision resistance	It's extremely hard to find two different inputs producing the same output	No one can forge a "looks-valid" fake transaction to replace a real one

Why Bitcoin does "double SHA-256"

Bitcoin's hash computations are almost all double SHA-256 — run the data through SHA-256 once, then run the result through SHA-256 a second time.

This design is an extra security layer added by Satoshi. Double SHA-256 not only adds a layer of security isolation, it also avoids potential problems like length-extension attacks that single hashing can face under the Merkle-Damgård structure.

An everyday analogy for hashing:

Hashing is like juicing — throw apples, oranges and watermelon into a juicer and you get a cup of liquid. You can't reverse-engineer what the original fruit looked like from that liquid, but if you have a suspicious apple slice, juice it again — if the resulting liquid has the same color, that apple slice has been "verified."

Merkle Tree: how to verify a transaction efficiently

The world without a Merkle Tree

Suppose a block has 2000 transactions. You want to verify whether the transaction "address A sent 0.5 BTC to address B" is in this block.

The dumbest method: download the whole block and check all 2000 records one by one.

With limited network bandwidth and some nodes being light wallets (phone wallets), this is unrealistic.

With a Merkle Tree

The Merkle Tree idea is hash layer by layer, pair by pair:

1. Hash each transaction's data separately, getting 2000 "leaf-node hashes";
2. Concatenate two adjacent leaf hashes and hash them, getting 1000 "second-layer hashes";
3. Keep pairing and hashing until only one hash remains — that's the Merkle Root.

When verifying a transaction, you don't need the whole block. You only need:

• The transaction's own data;
• A few hashes along the "path" from it to the Merkle Root (called a Merkle Proof).

For a block of 2000 transactions, you only need about log₂(2000) ≈ 11 hashes to complete verification.

This is the core principle of SPV (Simplified Payment Verification) — a phone wallet doesn't need to download the full Bitcoin blockchain (hundreds of GB) to verify transactions.

For how wallets work and their types, check out What is a crypto wallet? Addresses, seed phrases and asset security (2026).

Proof of work: what miners are actually "computing"

Many people say "miners are solving math problems," but that's not quite accurate.

A miner isn't solving an equation with a unique answer — they're doing one thing: repeatedly guessing a nonce (and an extension field) until the block header's double SHA-256 result falls below the difficulty target.

The specific process

1. The miner picks transactions from the mempool and builds a candidate block.
2. Fills in the five block-header fields (version, previous hash, Merkle Root, timestamp, difficulty target).
3. Starting from nonce = 0, computes SHA256(SHA256(block header)).
4. If the result ≥ difficulty target → nonce + 1, try again.
5. If the result < difficulty target → congratulations, you mined it! Broadcast to the whole network immediately.

Why this "problem" has no shortcut

SHA-256's output looks completely random. You can't "derive" which nonce will hit based on the target — you can only try them one by one.

It's like buying lottery tickets: each nonce change is scratching one ticket; to win you just scratch more. Bigger hashrate = scratching faster = higher win probability. This mechanism of competing for the right to keep the ledger via hashrate was fully laid out by Satoshi in sections 3-4 of the Bitcoin whitepaper.

How high is the difficulty

As of 2026, Bitcoin's difficulty target is extremely high — the actual criterion for a valid block hash is whether the hash value is below the target, not a fixed number of leading zeros. At current difficulty, a valid block hash usually contains a large number of leading zeros (about 20), which makes "leading zeros" a handy approximation, but the protocol doesn't actually count zeros.

The probability of finding a qualifying nonce is roughly 1/2²⁰⁰ — how big is that? About the probability of flipping a fair coin and getting 200 heads in a row.

All the ASIC miners in the network combined take about 10 minutes on average to find a valid nonce.

For a deeper understanding of blockchain technology, check out What is blockchain? Principles, uses and risks (2026).

Longest-chain rule: what happens when a fork occurs

If two miners mine a valid block almost simultaneously, the network briefly "forks" — some nodes receive block A first, others receive block B first.

Bitcoin's handling is very simple: follow the longest chain.

Subsequent miners pick one chain to keep mining on. When the next block is mined and added to one chain, that chain becomes longer — all nodes and miners switch to the longest chain.

Two consequences of this

1. Orphan blocks: the block on the abandoned shorter chain becomes an "orphan block," and its miner gets no block reward. This is one of the operational risks of mining.
2. Transaction confirmation isn't instant: once a transaction is packed into a block, if that block's chain is later abandoned, the transaction must re-queue for packing. This is why exchanges usually require 2-6 confirmations before crediting a balance.

The security of "6 confirmations"

Each additional confirmation means your transaction is buried one layer deeper in the chain. An attacker would have to recompute multiple blocks, starting from the block containing your transaction, to overtake the honest network on the longest chain. Satoshi used a probability model in section 11 of the whitepaper to prove that, as the number of confirmations grows, the probability of a successful attack falls exponentially — even with substantial hashrate, after 6 confirmations the probability of a successful double-spend is negligible.

6 confirmations isn't a magic number — it's an empirical balance between security and waiting time. For most everyday transfers, 2-3 confirmations are already secure enough.

How high is the cost of a 51% attack really

A 51% attack (majority-hashrate attack) is Bitcoin's most-discussed extreme scenario. The analysis below helps you understand why it's "theoretically possible, practically very hard."

What an attacker can do

Controlling over 50% of the network's hashrate, an attacker can:

• Take back coins they just spent (double-spend attack) — recompute the block containing their transaction and all subsequent blocks
• Prevent specific transactions from being confirmed — deliberately avoid packing certain addresses' transactions
• Steal others' coins — without others' private keys, they can't change others' signatures
• Create Bitcoin out of thin air — violates issuance rules, full nodes reject it outright
• Modify transactions in historical blocks — requires recomputing everything from the target block to the latest, demanding enormous hashrate

Cost estimate

As of 2026, Bitcoin's total network hashrate is in the hundreds of EH/s range (1 EH/s = 1 billion billion hashes per second), and it keeps growing. Real-time data is available via public block explorers.

Renting or buying enough ASIC miners to reach over 50% of the hashrate costs billions of dollars in hardware, plus the corresponding power infrastructure. On top of that, once the attack is detected, the Bitcoin price could crash — the attacker's BTC and mining rigs would all sharply lose value.

The net benefit of the attack is very likely negative. This is why the Bitcoin mainnet has run for over a decade without a single successful large-scale 51% attack.

For more on crypto security, check out How to prevent wallet theft? Seed phrases, wrong-chain transfers, approval risks (2026).

One table to summarize: Bitcoin blockchain's key parameters

Parameter	Value	Note
Block header size	80 bytes	Fixed size, doesn't change with transaction count
Average block size	~1.5 MB	Including transaction data; after SegWit it can reach ~2-3 MB
Average block time	~10 minutes	Maintained by automatic difficulty adjustment
Initial block reward	50 BTC	2009
Current block reward	3.125 BTC	After the 2024 halving, until ~2028
Final total supply	~21 million	Reached around 2140
Hash algorithm	SHA-256 × 2	Double SHA-256
Difficulty adjustment period	Every 2016 blocks	About 2 weeks
Network hashrate (2026)	Hundreds of EH/s	Changes in real time; queryable via block explorers

FAQ

Besides the block reward, what else can miners earn?

Each time a miner packs a block, they earn two parts: ① block reward (currently 3.125 BTC, issued by network rules); ② transaction fees (the sum of all fees in the block). As the block reward halves every four years, fees will gradually become the main income source for miners.

What happens if a miner packs an invalid transaction?

After receiving a new block, full nodes independently verify every transaction in it. If they find an invalid transaction (wrong signature, double-spend, minting coins out of thin air), full nodes reject the entire block and won't add it to the chain. The miner's hashrate is wasted — no block reward. So a rational miner won't take that risk.

Can Bitcoin's difficulty only go up, not down?

It can go down. Difficulty adjustment is two-way — if the past 2016 blocks took more than two weeks to produce (hashrate decreased), the difficulty auto-adjusts downward. Difficulty has dropped multiple times in history, usually after events like large-scale miner shutdowns or China's mining ban.

Why do full nodes need to store hundreds of GB of data?

Full nodes store the complete ledger from the genesis block (the first block in 2009) to the latest block. As of now, the total Bitcoin blockchain size is about 500-600 GB. Full nodes need complete data to independently verify every historical transaction. But you can run "pruned mode," keeping only recent block data + the full UTXO set, which shrinks it to a few GB.

Will Bitcoin's blocks ever "fill up"?

Yes, and it's an ongoing community discussion. Bitcoin mainnet throughput is limited by block size (~1-3 MB) and block time (~10 minutes) to roughly 3-7 transactions per second. When transaction demand is high, the mempool gets congested and fees rise. Scaling solutions include the Lightning Network (off-chain payment channels), sidechains and future soft-fork upgrades — this remains an active area of technical evolution.

What is Bitcoin's block size? Why can't it just be expanded?

Bitcoin's block size is limited to 1 MB (after the SegWit upgrade it can effectively reach about 2-3 MB). This limit was set by Satoshi early on to prevent spam-transaction attacks. Scaling solutions are constantly discussed in the community: keep the main chain decentralized (anyone can run a full node), and route high-frequency small payments through Layer-2 solutions like the Lightning Network. It's the classic "security/decentralization vs throughput" trade-off.

Why can't historical transactions be modified?

Because every block contains the previous block's hash — change any historical transaction and that block's hash changes, every subsequent block's "previous block hash" no longer matches, and the whole chain breaks from the modification point onward. An attacker would have to recompute all the PoW from the modified block to the latest block, while honest miners keep extending the latest chain — the probability of catching up falls exponentially with the number of confirmations. That's the real meaning of the word "chain."

What's the relationship between private keys and the Bitcoin network's operation?

The Bitcoin network's operation doesn't depend on anyone's private key. But initiating a transaction requires a private-key signature — your private key is your "digital signing pen," proving you have the right to use the BTC in a certain address. A private key doesn't need to be online; it can even be written on paper. For private-key custody, check out What is a seed phrase? Why no one can help you recover your assets if you lose it (2026).

Summary

The Bitcoin blockchain's operating mechanism, at its core, is the following interlocking designs:

1. UTXO model → Bitcoin doesn't record "balances," only unspent transaction outputs, circulating like banknotes;
2. Blocks + chained hashing → makes history hard to tamper with (changing one = changing the whole chain);
3. Merkle Tree → lets anyone verify transactions efficiently without downloading a whole block;
4. SHA-256 → one-way, avalanche, collision-resistant, forming the cryptographic foundation;
5. Proof of work (PoW) → replaces centralized voting with hashrate competition, giving "who decides" an economic cost;
6. Longest-chain rule → resolves fork conflicts with the simplest rule, so the whole network auto-converges to one state.

Together, these designs let a network with no central server, no company, and no CEO coordinate across tens of thousands of nodes worldwide for over a decade.

For beginners, you don't need to memorize the byte count of every field. Just remember one thing: Bitcoin's security doesn't come from "nobody attacks," but from "the cost of attacking far outweighs the benefit."

Next, it's worth understanding Bitcoin's full transaction flow — what a BTC transfer goes through from initiation, broadcast, entering the mempool, to being packed into a block and reaching 6 confirmations. Check out the follow-up articles in this series.

Related reading

• Why doesn't Bitcoin need banks? UTXO, nodes, PoW — part 1 of this series
• What is Bitcoin (BTC)? Principles, value and risks (2026) — BTC basics
• What is blockchain? Principles, uses and risks (2026) — a full blockchain overview
• How to prevent wallet theft? Seed phrases, wrong-chain transfers, approval risks (2026) — asset security
• What is a crypto wallet? Addresses, seed phrases and asset security (2026) — wallet basics

Disclaimer

This article is for Bitcoin and blockchain technical education only and does not constitute investment, financial or trading advice.

Crypto asset prices are volatile, and related services may carry platform risk, market risk, network security risk and operational risk. Users should judge carefully based on their own risk tolerance and follow the laws and regulations of their location.