BIP 159

BIP-159 defines the NODE_NETWORK_LIMITED service bit, which lets a Bitcoin node advertise that it stores only recent blocks (typically the last 288 blocks, about 2 days) rather than the full chain.

The point: not every node needs the full chain to be useful. A node that serves the last 2 days of blocks can still:

• Help peers stay in sync when they're catching up on recent activity.
• Validate the current chain tip for itself.
• Relay new transactions and blocks as they come in.

What it gives up: the ability to serve historical blocks to fresh-syncing peers doing an initial download from genesis. Those peers need at least some full-history peers to bootstrap.

Why this matters:

• Pruned nodes can announce themselves cleanly. Bitcoin Core's pruning mode (which automatically discards old blocks after a configurable size limit) was awkward without NODE_NETWORK_LIMITED - other peers might try to request old blocks from a pruned node and get refused. BIP-159 lets the pruned node announce its capability upfront.
• More nodes can run on small hardware. Storing 2 days of blocks takes far less space than keeping the full history, which Bitcoin Core 31 estimates needs at least 870 GB of disk (October 2026). Raspberry Pi-class nodes become more viable.
• The network gets more nodes total. Lowering the disk requirement increases participation.

The fresh-sync problem (someone has to serve historical blocks to new nodes) is real but solvable: the network needs some full-history nodes, not all nodes to be full-history. As long as enough full nodes exist, NODE_NETWORK_LIMITED nodes can fill in the bulk of recent-block-serving demand.

This is one of the small, sustained improvements that have made running a Bitcoin node more accessible over the years.