A bitcoin.conf for a machine that does not have the RAM
Run a Bitcoin node on a machine that does not have the RAM, and write down what each setting actually costs.
A bitcoin.conf and an explanation. Narrow, verifiable, useful.
dbcache is the main lever everyone reaches for. Lowering it cuts memory
directly and lengthens initial block download considerably, because the UTXO set
spills to disk more often. A real trade with a number attached, and the right
value depends on whether you care more about getting synced or about the machine
staying usable while it does.
maxmempool bounds the transaction pool. Lowering it caps memory and changes
which transactions you relay, because a smaller pool evicts by fee rate and you
stop propagating the low-fee end. That changes your participation in the
network, not only your resource usage. maxconnections and par trade
throughput and peer diversity for footprint.
prune is the one with consequences. A pruned node validates everything and
keeps the full UTXO set; it does not keep old blocks, so it cannot serve them to
a syncing peer. Fully validating, not fully serving, a distinction usually
flattened into “pruned nodes are lesser”, which is wrong in the way that matters
to you and right in the way that matters to the network.
The number to trust is measured resident memory.