Bitcoin Core Blocks-Only Mode for Bandwidth-Controlled Nodes

This guide explains Bitcoin Core blocksonly mode in plain English. It focuses on what the subject is, why it matters and what a beginner should remember.

What the option changes

With blocksonly enabled, the node avoids requesting and relaying ordinary transactions from normal peers. It remains connected for headers and blocks and validates the active chain. Dashboards must therefore distinguish a deliberately sparse mempool from a stalled node or broken peer connection.

Wallet broadcasting interaction

The 0.12 startup logic disabled walletbroadcast in blocks-only mode. A local wallet transaction needed an explicit alternative path or manual broadcast. An operator could not assume that creating and signing through the same node meant the transaction reached the network.

Whitelist relay

The historical implementation also changed whitelistrelay defaults in blocks-only mode, while explicitly whitelisted peers could have different relay treatment under configuration. A trusted peer path must be deliberate and narrow. Whitelisting is a policy exception, not authentication of every transaction or protection against resource abuse.

Mining template consequences

A blocks-only node without a transaction feed builds templates from a thin or empty mempool and can lose fee revenue. A pool might pair it with a trusted transaction source, but the validating template node must still verify every candidate transaction. Failover must preserve both consensus validity and the intended mempool feed.

Bandwidth and privacy

Reducing transaction gossip lowers traffic and may reveal less about local transaction interests, but peer metadata and block downloads remain. A distinctive connectivity pattern can itself fingerprint the node. Maxuploadtarget and pruning solve different outbound and storage problems and should be evaluated separately.

Monitoring design

Expected mempool size and transaction rate depend on the chosen trusted-peer exceptions. Alert on chain lag, block propagation, peer loss and template fee deltas, not simply a zero mempool. Record whether the node is validation-only, wallet-facing, mining-primary or emergency failover because acceptable behaviour differs.

Operational rehearsal

Run two isolated nodes with one in blocks-only mode. Broadcast transactions through ordinary and whitelisted paths, create a wallet spend, mine blocks and compare templates and fees. Restart into failover, verify transaction-source restoration and prove the node never treats unvalidated external template content as trusted.

Conclusion

Blocks-only mode is valuable for constrained validation and specialised topology, but it deliberately removes ordinary transaction relay. Wallet and mining deployments need an explicit, tested transaction path and monitoring that understands the reduced-mempool design.