Reading the Live Chain & Block Explorers

This is the payoff of the whole book. Every field you’ve studied — headers, Merkle roots, inputs, outputs, fees, the coinbase — is sitting in the live chain right now, readable by anyone. This page shows you how to inspect it, and, more importantly, how to verify what a block explorer tells you instead of trusting it.

Block explorers vs your own node

A block explorer (a website that lets you search blocks, transactions, and addresses) is convenient — but it’s a third party telling you what the chain says. That’s a trust assumption, and this whole book has been about removing those.

  Block explorer            Your own node
  ───────────────           ──────────────
  fast, no setup            you ran the validation
  someone else's claim      first-hand truth
  can lie or be wrong       "don't trust, verify"
  fine for casual lookups   required for anything that matters

Use explorers to find things quickly; use your own node to confirm anything you actually rely on. The rest of this page does both.

Walk the chain from the tip

# where is the chain tip right now?
bitcoin-cli getblockchaininfo        # blocks, bestblockhash, chainwork

# get the hash of a specific height, then the block
hash=$(bitcoin-cli getblockhash 800000)
bitcoin-cli getblock "$hash" 1       # verbosity 1: header fields + tx ids

Everything in that output maps to The Block Header (80 bytes): version, previousblockhash, merkleroot, time, bits (the target), and nonce, plus the list of transaction ids committed by the Merkle root.

Read a transaction’s anatomy

# pick a txid from the block above, then decode it
bitcoin-cli getrawtransaction <txid> true

Match the decoded fields back to Anatomy of a Transaction:

• vin — each input referencing a previous output by (txid, vout) plus its witness/scriptSig.
• vout — each output’s value (in BTC; ×100,000,000 for sats) and its scriptPubKey (the lock).
• The fee isn’t a field — it’s sum(inputs) − sum(outputs), exactly as in Fees, Change & the Conservation Rule. To get input values you look up each referenced output.

fee = (Σ input values)  −  (Σ output values)
      └ found by looking up each vin's prior output ┘

Spot the coinbase

The first transaction in every block is the coinbase (see Coinbase Transactions). It’s unmistakable: its single input has no real txid (it shows coinbase instead of referencing a prior output), and its outputs pay the miner the subsidy + fees.

# the first txid in a block's tx list is the coinbase
bitcoin-cli getblock "$hash" 2 | head   # verbosity 2 expands full tx data

Reading the coinbase value against the halving schedule tells you which subsidy era the block is in — and the leftover above the subsidy is the total fees that block collected.

A concrete worked example — the math is verifiable

Block height 840,000 is past the 4th halving, so its subsidy is 50 → 25 → 12.5 → 6.25 → 3.125 BTC. Say getblock shows its coinbase paying 3.2 BTC. Then the block’s total fee income is just subtraction:

total fees = coinbase payout − subsidy
           = 3.2 BTC − 3.125 BTC = 0.075 BTC

You’ve derived a block’s entire fee income from two numbers — the payout you read and the subsidy you computed from the height. (The halving math is exact; the 3.2 BTC payout is illustrative — plug in the real value your node returns.)

Is an output still spendable?

# is this (txid, vout) still in the UTXO set?
bitcoin-cli gettxout <txid> <vout>

A result means the output is unspent (it’s in the live UTXO set); null means it’s already been spent. This is the exact check every node does to detect double-spends.

Verify, don’t trust: catch an explorer

Here’s the habit that ties everything together. Look up a transaction’s confirmation count or a block’s Merkle root on a public explorer, then confirm it against your own node:

# does the explorer's claimed block hash for height N match yours?
bitcoin-cli getblockhash <N>

# does a tx the explorer shows "in block X" really commit under that block's merkleroot?
bitcoin-cli gettxoutproof '["<txid>"]' <blockhash>   # build the Merkle proof
bitcoin-cli verifytxoutproof <proof-hex>             # your node re-checks it

If your node agrees, you’ve verified rather than trusted — exactly the technique from Verify a Merkle Proof Yourself. If it ever disagrees, believe your node.

Why an explorer can be wrong in the first place

It’s not only about lying — an explorer is a centralized index backed by its own node(s), and it can be honestly mistaken:

• It may be a few blocks behind (stale cache) — its “0 confirmations” is really 3.
• Its node could be on a minority fork mid-reorg, showing a view that won’t survive.
• It could itself be eclipsed — fed a false chain by malicious peers (see network attacks) — so even its sincere answers are wrong.

Concretely: an explorer shows your payment “confirmed in block N,” but bitcoin-cli getblockhash N returns a different hash than the block it claims. Believe your node — it validated every rule itself; the explorer just asked someone else.

How does this help untrusting strangers agree on one ledger? Because you can now read every field the ledger contains and re-check any claim about it against rules you understand, you no longer need to trust an explorer, an exchange, or a counterparty’s word. That’s the entire promise of Bitcoin made concrete: a ledger that mutually-distrusting strangers agree on not because someone vouches for it, but because each of them can read and verify it independently. You can now do that. You’ve finished the deep dive.

Check your understanding

1. What trust assumption does a block explorer introduce, and how do you remove it?
2. Given a block hash, which command shows its header fields, and which header field commits to all the transactions?
3. A transaction has no fee field. How do you compute the fee it paid?
4. How can you tell, from decoded data, that a transaction is the coinbase?
5. Describe how you’d verify — not just trust — that an explorer’s “this tx is in block X” claim is true.

Show answers

1. An explorer is a third party telling you what the chain says — a trust assumption (it can be stale, on a minority fork, eclipsed, or simply lying). You remove it by confirming any claim against your own node, which validated every rule itself; if they ever disagree, believe your node.
2. bitcoin-cli getblock "$hash" 1 shows the header fields (version, previousblockhash, merkleroot, time, bits, nonce) plus the txid list. The merkleroot is the field that commits to all the transactions in the block.
3. The fee is sum(inputs) − sum(outputs) — there’s no fee field. You get the output values directly from vout, and the input values by looking up each vin’s referenced prior output. (See Fees, Change & the Conservation Rule.)
4. The coinbase is the first transaction in the block, and its single input has no real txid — it shows coinbase instead of referencing a prior output — while its outputs pay the miner the subsidy + fees.
5. Build a Merkle proof and have your own node re-check it: bitcoin-cli gettxoutproof '["<txid>"]' <blockhash> then bitcoin-cli verifytxoutproof <proof-hex>. If your node hashes the branch up to the block’s committed Merkle root and returns the txid, the claim is verified, not trusted; cross-check the block hash for that height with getblockhash <N> too. (See Verify a Merkle Proof Yourself.)