Bitcoin is software and an incentive system. If you only memorize data structures, you will still be surprised when fees spike or blocks fill.
Complete Step 1 // Required reading in the study plan above, then continue here. Use your Foundations regtest node for the hands-on step.
Step 2 — Core idea: supply, fees, security
| Term | Meaning | Builder impact |
|---|---|---|
| Block subsidy | New bitcoin paid to the miner | Shrinks over halvings |
| Halving | Subsidy cut ~every 210,000 blocks | Security shifts toward fees |
| Fee / sat/vB | What users bid for block space | Wallet urgency |
| Mempool | Waiting room for unconfirmed txs | Fee market venue |
Analogy: Block space is seats on a fixed-size bus every ~10 minutes. High demand → higher fares. Miners earn fare box + subsidy.
const feeSats = inputSumSats - outputSumSats;
const satPerVb = feeSats / virtualSize;Loading diagram…
Design for fee spikes (RBF/CPFP), dust UTXOs, and different confirmation targets.
Done when: You can point to subsidy and fees in the Mermaid flow.
Step 3 — Try it on regtest (lab)
ADDR=$(bitcoin-cli -regtest getnewaddress)
bitcoin-cli -regtest generatetoaddress 1 "$ADDR"
bitcoin-cli -regtest getbalanceRemember: coinbase needs 100 confirmations before spend — mining many blocks or observing immature balance is fine.
Then compute fee / approximate sat/vB for any lab send or decoded example. One sentence: what breaks if a wallet hard-codes 10 sat/vB forever?
Common mistakes
- Hard-coding fees forever
- Treating the 21M cap as UX fluff
- Assuming Lightning removes on-chain fee literacy
Done when: Lab evidence (balance output + fee calc + source link) is complete.
Next lesson
Start UTXO Model — the accounting system every wallet actually uses. Basics labs assume your local regtest chain.