MASTERING-BITCOIN · Interactive Practice | Unit 6 · Video 2
Outpoint anatomy — a 36-byte pointer to exactly one previous output:
| Field | Size | Purpose |
|---|---|---|
| txid | 32 bytes | Identifies the previous transaction |
| output index | 4 bytes | Selects which output within that transaction |
compactSize encoding — Bitcoin's variable-length integer encoding:
| Value Range | Prefix Byte | Total Bytes |
|---|---|---|
| 0–252 | (none) | 1 |
| 253–65,535 | 0xfd | 3 |
| 65,536–4,294,967,295 | 0xfe | 5 |
| 4,294,967,296+ | 0xff | 9 |
Core rule: A transaction is valid only if every input's outpoint references an output that currently exists in the UTXO (Unspent Transaction Output) database.
Bitcoin uses compactSize to encode counts (like the number of inputs in a transaction) using as few bytes as possible. Pick a value to see how it gets encoded.
Reflect: Why is compactSize designed so that small values (which are by far the most common) take only one byte, while only large values pay the cost of extra bytes?
⚙ interactive visualization — coming to this page format soon
A full node validates each transaction by checking that every input's outpoint references an output that is still in the UTXO database. Try the three scenarios below to see how the node responds.
Notice: the UTXO database — not miners — is what enforces the no-double-spend rule. Every full node maintains its own copy and rejects invalid transactions independently.
⚙ interactive visualization — coming to this page format soon
Inside a serialized transaction, txids are stored in little-endian byte order.
But block explorers and bitcoin-cli display them in big-endian order — the
full 32-byte sequence reversed. Pick an example to see what this looks like.
Notice: the bytes are not partially reversed and they are not displayed as-is — the entire 32-byte sequence is reversed end-to-end.
⚙ interactive visualization — coming to this page format soon
Question 1
A transaction has 300 inputs. The number of inputs is encoded with compactSize at the start of the transaction. How many total bytes does this count field occupy?
✅ Correct! 300 is above 252, so compactSize uses the 0xfd prefix plus 2 data bytes — 3 bytes total.
❌ Not quite. A single byte only fits values 0–252. 300 is just over that limit.
❌ Not quite. 300 is small enough to fit in the 3-byte encoding (0xfd + 2 data bytes). The 5- and 9-byte encodings are reserved for much larger values.
Solution:
The value 300 falls in the range 253–65,535, so compactSize uses:
0xfd2c 01Total: 3 bytes.
Only values 0–252 fit in a single byte with no prefix.
Question 2
An outpoint is the field in a transaction input that points to the previous output being spent. Which option correctly describes the outpoint's structure and total size?
✅ Correct! An outpoint is just txid (32) + output index (4) = 36 bytes. The input itself carries no amount; the node looks the amount up in the UTXO database.
❌ Not quite. The amount is not stored in the input. Inputs hold no value on their own — they only point to a previous output, and the node looks the amount up in the UTXO database.
❌ Not quite. Check the field sizes: txid is 32 bytes (a full hash) and the output index is 4 bytes.
Solution:
An outpoint is a pointer, not a value. It contains exactly two fields:
Total: 36 bytes.
The amount is not part of the outpoint. The node looks the amount up in the UTXO database after using the outpoint to find the referenced output.
Question 3
True or False: Miners are the primary mechanism that prevents double-spending in Bitcoin. If a miner accepts a double-spend transaction into a block, the rest of the network is forced to accept it.
✅ Correct! Every full node enforces the no-double-spend rule independently. A miner who includes a double-spend just produces a block that the rest of the network rejects.
❌ Not quite. This is a common misconception. Miners order transactions, but the no-double-spend rule is enforced by every full node against its own UTXO database. A block containing a double-spend is rejected by the network.
❌ Not quite. Try again — the hints above can help.
Solution:
False. Every full node enforces the no-double-spend rule independently by maintaining its own UTXO database.
When a node receives a new block:
If a miner produces a block containing a double-spend, every other full node detects the conflict and rejects the entire block as invalid — the malicious miner wastes their work. Mining provides ordering and finality, but the actual double-spend prevention is enforced by every node, every time.
Question 4
A serialized transaction stores a txid as 32 bytes in little-endian order,
beginning with 1a 2b 3c 4d ... and ending with ... e7 f8.
What does the same txid look like when displayed in a block explorer (big-endian)?
✅ Correct! The full 32-byte sequence is reversed end-to-end, so the byte that was first in the serialized txid is last in the displayed txid.
❌ Not quite. Display tools and the serialized format use different byte orders. That mismatch is exactly what trips up developers: a copy-pasted little-endian txid won't be found by bitcoin-cli.
❌ Not quite. It isn't a partial reversal — all 32 bytes are reversed end-to-end. The first byte becomes the last byte.
❌ Not quite. It's not a pairwise swap — the whole 32-byte sequence is reversed end-to-end.
Solution:
To convert between little-endian (serialized) and big-endian (display), you reverse the entire 32-byte sequence end-to-end. The byte that was first becomes last, and vice versa.
If the serialized form is:
1a 2b 3c 4d ... e7 f8
then the display form is:
f8 e7 ... 4d 3c 2b 1a
This is the most common pitfall when working with raw transactions:
bitcoin-cli getrawtransaction returns
"No such mempool or blockchain transaction".This quirk is an artifact of Bitcoin's earliest code and is now permanent.
Solved: 0 / 4