MASTERING-BITCOIN · Unit 3 · Video 4 · Interactive Practice
| Command / Concept | Purpose | Pattern |
|---|---|---|
getblockhash <height> then getblock <hash> |
Two-step block lookup | Height → Hash → Block Data |
getrawtransaction <txid> then decoderawtransaction <hex> |
Two-step tx decode | TxID → Raw Hex → Structured JSON |
| Fee | Mining fee (implicit) | Never stated explicitly in tx data |
gettxoutsetinfo |
Supply audit | Returns total UTXO count and verified supply |
A Bitcoin transaction consumes inputs (references to previous unspent outputs) and creates new outputs. The mining fee is never explicitly stored in the transaction — it equals the difference between total input value and total output value.
Adjust the amounts below to explore how inputs and outputs determine the fee a miner collects.
⚙ interactive visualization — coming to this page format soon
💡 Explore: Try making the outputs exceed the inputs — what happens? Try setting the fee to nearly zero. In real Bitcoin, the fee incentivizes miners to include your transaction; a higher fee typically means faster confirmation. The key insight: the fee is never an explicit field in the transaction data.
When you run getblock, the returned JSON includes a confirmations field — how many blocks have been built on top of the target block (including the block itself). Each additional confirmation makes a chain reorganization exponentially more expensive. The traditional high-confidence threshold is 6 confirmations.
Adjust the sliders to see how confirmations change with chain length and block position.
⚙ interactive visualization — coming to this page format soon
💡 Observe: As you extend the chain or move the target earlier, confirmations grow. At 6 confirmations, you reach the traditional "high confidence" threshold. Each additional confirmation makes a reorganization attack exponentially more expensive because an attacker would need to redo the proof-of-work for every subsequent block.
Every transaction input contains a txid pointing to a previous transaction and a vout index identifying which output is being spent. Following these references backward always terminates at a coinbase transaction — the first transaction in a block, which mints new bitcoin with no prior input references.
Increase the trace depth to follow the chain all the way to the coinbase.
⚙ interactive visualization — coming to this page format soon
💡 Key Insight: Bitcoin is not a balance in an account. It's a chain of signed ownership transfers, each independently verifiable, stretching back to the moment those coins were minted. Set the depth to 5 to see the complete trace to the coinbase origin.
Question 1
You want to inspect the full data for the block at height 123,456 using bitcoin-cli. What is the correct command sequence?
✅ Correct! The two-step pattern — height to hash, then hash to data — is the fundamental block lookup.
❌ Not quite. Remember: Bitcoin Core indexes blocks by hash, not height. You need two separate commands.
Solution:
Bitcoin Core indexes blocks by hash, not by height. The lookup always requires two steps:
bitcoin-cli getblockhash 123456 — returns the 64-character hex hashbitcoin-cli getblock <hash> — returns the full block data as JSONThe command getblock requires a hash as input, not a height number. getblockinfo is not a real Bitcoin Core RPC command, and decoderawtransaction is used for transactions, not blocks.
Question 2
A transaction has two inputs totaling 0.600 BTC and two outputs totaling 0.595 BTC. Where is the 0.005 BTC mining fee recorded in the transaction data?
✅ Correct! The fee is always implicit — the difference between total inputs and total outputs.
❌ Not quite. There is no explicit fee field anywhere in a Bitcoin transaction.
Solution:
The mining fee is never an explicit field in Bitcoin transaction data. It must be computed:
To calculate a transaction's fee, you must look up each input's referenced previous output to find its value, then subtract the sum of all outputs. The miner who includes this transaction in a block claims the implicit difference.
Question 3
When you trace a transaction's inputs backward — following each input's referenced txid to its source — what type of transaction terminates the chain?
✅ Correct! Coinbase transactions mint new bitcoin — they're where every backward trace ends.
❌ Not quite. Think about where brand-new bitcoin is created — which type of transaction has no prior inputs?
Solution:
Every chain of transaction inputs eventually terminates at a coinbase transaction — the first transaction in every block. Coinbase transactions create new bitcoin as the mining reward and have no inputs referencing prior transactions, because those coins did not exist before.
This reveals Bitcoin's fundamental nature: it is not a balance in an account, but a chain of signed ownership transfers stretching back to the moment each coin was minted.
Question 4
True or False: When you run gettxoutsetinfo on your own fully-synced Bitcoin node, the total supply figure it reports was computed locally by your node validating every transaction since the genesis block — without querying any external server.
✅ Correct! Your node independently verifies the entire supply — this is self-sovereign verification in action.
❌ Not quite. Remember: bitcoin-cli commands query your own node's locally verified data, not an external source.
Solution: True
Your Bitcoin node validates every transaction from the genesis block (January 2009) forward during initial sync. The command gettxoutsetinfo returns:
This is the operational meaning of "don't trust, verify" — your node computed this figure locally by checking every block against the consensus rules. No external server was consulted.
Solved: 0 / 4