MASTERING-BITCOIN · Interactive Practice | Unit 6 · Video 6
| Formula | Name | Description |
|---|---|---|
| Lock time threshold | Below = block height, at/above = epoch seconds | |
| Block subsidy (sats) | Halves every 210,000 blocks | |
| Transaction weight | Block max = 4,000,000 WU | |
| Virtual bytes | Used for fee rate (sat/vbyte) |
A transaction's lock time is a single 4-byte unsigned integer, but its meaning depends on whether the value is below or above 500,000,000. Use the slider to scan across the full uint32 range and watch how the interpretation switches at the threshold.
Conceptual question: Why did Bitcoin's designers choose 500,000,000 as the threshold, and what would the value 1,700,000,000 mean?
⚙ interactive visualization — coming to this page format soon
Notice: A lock time of 0 imposes no restriction at all. Once you cross 500,000,000, you've left the block-height world (block 500M is far in the future) and entered the Unix-timestamp world. The network checks lock time against median time past (the median of the previous 11 block timestamps), so it lags real time by 1–2 hours.
Every coinbase transaction's outputs are capped at the block subsidy plus all fees. The subsidy starts at 50 BTC and halves every 210,000 blocks. Drag the slider to a block height and see which halving epoch it falls into.
Conceptual question: At what block height does the subsidy first drop below 1 BTC?
⚙ interactive visualization — coming to this page format soon
Reflect: The total bitcoin ever issued is the area under this step function, which converges to just under 21 million BTC. Also remember: a coinbase output cannot be spent until 100 confirmations have passed — this prevents a chain reorganization from invalidating downstream transactions when the original coinbase disappears.
Bitcoin charges factor 4 for non-witness bytes and factor 1 for witness bytes. This means the same byte costs 4x more if it lives outside the witness section. Adjust the byte counts and watch how raw size, weight, and vbytes diverge.
Conceptual question: Two transactions have the same total raw size. The first puts most data in the witness; the second is a legacy transaction with no witness at all. Which one pays a lower fee?
⚙ interactive visualization — coming to this page format soon
Notice: When witness bytes make up a large share of the raw size, they shrink dramatically as a share of weight. Push the witness slider up and the non-witness slider down to see the discount in action. This is exactly why spending a UTXO (which requires witness data) is cheaper per byte than creating new outputs — a deliberate design choice to fight UTXO set bloat.
Question 1
A transaction has lock time set to 750,000. What does this mean?
✅ Correct! 750,000 is well below the 500,000,000 threshold, so it's a block-height lock.
❌ Not quite. Compare 750,000 against the threshold of 500,000,000.
Solution:
Lock time uses the threshold to decide its interpretation:
Since , this is a block-height lock. The transaction is invalid (cannot be included in a block) until block 750,000 has been reached, as measured by median time past (the median of the previous 11 block timestamps).
Lock time also only restricts the earliest point of inclusion — it never expires the transaction. A value of zero would mean no restriction at all.
Question 2
A miner builds a coinbase transaction at block height 840,000. Total transaction fees collected from the block are 0.5 BTC. What is the maximum total output value the coinbase transaction may have?
✅ Correct! Subsidy after 4 halvings is 3.125 BTC, plus 0.5 BTC fees.
❌ Not quite. First find the halving epoch (height / 210,000), then compute the subsidy and add the fees.
Solution:
Compute the halving epoch:
So the subsidy is:
The coinbase rule states that outputs cannot exceed subsidy + fees:
Note: a miner is allowed to claim less than this, but never more. Also, these outputs require 100 confirmations (the maturity window) before they can be spent.
Question 3
A SegWit transaction has 120 non-witness bytes and 80 witness bytes. What is its weight in weight units (WU)?
✅ Correct! 120×4 + 80×1 = 560 WU (= 140 vbytes).
❌ Not quite. Multiply non-witness bytes by 4, witness bytes by 1, then sum.
Solution:
Apply the weight formula with factor 4 for non-witness, factor 1 for witness:
Common wrong answers:
In virtual bytes: vbytes, which is what fee rates (sat/vbyte) are quoted against.
Question 4
True or False: A legacy (non-SegWit) transaction that has no witness data has a weight equal to exactly 4 times its raw byte count.
✅ Correct! With no witness data, every byte is factor-4, so weight = 4 × raw size.
❌ Not quite. Without any witness section, all bytes fall into the factor-4 category.
Solution: True
A legacy transaction omits the SegWit-specific fields entirely: the marker byte, the flag byte, the witness item count, and the witness items themselves. Every byte that remains (version, inputs, outputs, lock time, etc.) carries the factor-4 multiplier.
Therefore:
This is precisely what the witness discount rewards: SegWit transactions can place a portion of their data in the factor-1 witness section, lowering their total weight (and fee) relative to a legacy transaction with the same raw size.
This connects directly to the design goal — making it cheaper to spend UTXOs (which requires witness data) than to create them, helping fight UTXO set bloat.
Solved: 0 / 4