MASTERING-BITCOIN · Interactive Practice | Unit 3 · Video 3

One Node, 100+ Settings: Tuning Bitcoin Core

IKey Configuration Reference

Setting	Values	Effect	Trade-off
`prune=N`	0 (off) or $\geq 550$ MiB	Deletes old blocks after validation	Saves disk $\leftrightarrow$ Loses history serving
`txindex=1`	0 or 1	Indexes every transaction by ID	Full lookups $\leftrightarrow$ Costs disk space
`dbcache=N`	150–4096+ MiB (default 450)	UTXO set cache size in RAM	Faster I/O $\leftrightarrow$ Costs RAM
`blocksonly=1`	0 or 1	Stops relaying unconfirmed txs	Saves bandwidth $\leftrightarrow$ No mempool visibility

⚠️ Critical constraint: txindex and prune are mutually exclusive — you cannot index transactions from blocks you've already deleted.

IIVisualization 1: Disk Growth Over Time

How does pruning affect long-term storage requirements?

The full Bitcoin blockchain exceeds 550 GB and grows by ~400 MB per day. Use the sliders below to explore how the prune setting changes your disk footprint over months and years.

⚙ interactive visualization — coming to this page format soon

💡 Notice: The full-node line rises steadily (~146 GB per year) while the pruned node stays flat near zero. After 36 months a full node exceeds 980 GB. What happens if you raise the prune value to 5000 MiB? It barely moves the green line — because even ~5 GB is tiny compared to 550+ GB. This is why pruning is so powerful on constrained hardware.

IIIVisualization 2: Memory Budget Allocator

How do dbcache and maxmempool compete for your system's RAM?

Bitcoin Core needs RAM for the UTXO cache (dbcache), the mempool (maxmempool), and its own process overhead (~400 MiB). Adjust the sliders to see how these allocations fit within different hardware budgets.

⚙ interactive visualization — coming to this page format soon

💡 Try this: Set total RAM to 1024 MiB (Raspberry Pi) and raise dbcache above 200. Notice how quickly you blow the budget! On a 1 GB device, dbcache=150 and maxmempool=50 is about the maximum safe configuration. Now set RAM to 16384 MiB and see how much headroom a server has for dbcache=2048.

IVVisualization 3: Setting Trade-off Explorer

What does each setting cost, and what does it buy you?

Toggle individual Bitcoin Core settings on and off to see how they shift the balance between resource consumption and node functionality. Remember: every feature costs something — there's no free lunch.

⚙ interactive visualization — coming to this page format soon

💡 Explore: Enable both txindex and prune to see the incompatibility warning — Bitcoin Core will refuse to start with both enabled. Then try the "API backend" combo (txindex + high dbcache) versus the "Raspberry Pi" combo (prune + blocksonly). Can you find a configuration that minimizes all three resource bars while keeping functionality high? Why is that impossible?

VQuiz Questions

Question 1

What is the minimum value you can set for the prune configuration option in Bitcoin Core?

✅ Correct! 550 MiB is the minimum prune value, ensuring safe operation during chain reorganizations.

❌ Not quite. The minimum is higher than you might expect — the node needs enough room to handle block reorganizations safely.

Show solution

Solution: 550 MiB

The minimum prune value in Bitcoin Core is 550 MiB. This hard-coded minimum ensures the node retains enough recent block data to handle chain reorganizations safely.

With prune=550, your node still downloads and validates every single block from genesis — it simply deletes old block data after verification, keeping disk usage around 550 MiB instead of 500+ GB.

Question 2

True or False: Enabling prune mode weakens your node's transaction validation — a pruned node only checks some blocks, not all of them.

✅ Correct! Pruning saves disk but does NOT weaken validation. Every block is fully validated before old data is deleted.

❌ Not quite. Think about the order of operations: does the node delete first and then validate, or validate first and then delete?

Show solution

Answer: False

This is one of the most common misconceptions about pruning. A pruned node:

Downloads every block from genesis to the current tip
Validates every transaction and block against the full consensus rules
Deletes old block data only after successful verification

Pruning affects storage, not validation rigor. The only capabilities you lose are:

Serving historical blocks to other peers
Using txindex to look up arbitrary past transactions
Re-scanning old blocks for wallet history

Your node enforces the exact same consensus rules whether pruned or not.

Question 3

You want to build a block explorer that can look up any historical transaction by its ID. Which configuration pair is correct?

✅ Correct! A block explorer needs txindex for full lookups AND the complete blockchain on disk (no pruning).

❌ Not quite. Remember: which two settings are mutually exclusive? And which single setting enables full transaction lookups?

Show solution

Answer: txindex=1 and prune=0 (disabled)

To look up any historical transaction by its ID you need both:

txindex=1 — builds a complete index of every confirmed transaction, not just your wallet's.
prune=0 (disabled) — keeps the full blockchain on disk so txindex can read historical block data.

Why the other options fail:

Option	Problem
txindex=1 + prune=550	Mutually exclusive — Bitcoin Core refuses to start
txindex=0 + prune=550	No transaction index — can't look up arbitrary txs
blocksonly=1 + txindex=1	`blocksonly` only affects bandwidth, not lookups — this is incomplete without explicitly disabling prune

The critical rule: you cannot index transactions from blocks you've already deleted.

Question 4

The blockchain currently occupies 550 GB and grows by approximately 400 MB per day. If you run a full (unpruned) node, approximately how much total disk space will the blockchain need after one year (365 days)?

$\text{Total} = \text{Initial size} + (\text{daily growth} \times \text{days})$

✅ Correct! 550 + (0.4 × 365) = 550 + 146 = 696 GB. Plan your storage accordingly!

❌ Not quite. Remember: total = initial size + growth. Convert 400 MB to 0.4 GB, then multiply by 365 days.

Show solution

Answer: About 696 GB

$\text{Total} = 550\;\text{GB} + (0.4\;\text{GB/day} \times 365\;\text{days})$ $= 550\;\text{GB} + 146\;\text{GB} = 696\;\text{GB}$

Common mistakes:

Wrong answer	Error
146 GB	That's only the growth — forgot to add the initial 550 GB
550 GB	Assumes the chain stops growing (it doesn't!)
950 GB	Would require ~2.7 years of growth from 550 GB

This is exactly why disk planning matters — and why prune is so valuable on constrained hardware.

Solved: 0 / 4