Block-Relay-Only Connection

A block-relay-only connection is a special type of outbound link that a Bitcoin Core node opens for the purpose of exchanging blocks while deliberately suppressing transaction relay and address (addr) gossip. Introduced through pull request #15759 in 2019, these connections give a node a second, quieter channel to the block-producing network alongside its ordinary full-relay peers — a defensive layer that runs silently on every modern node, including the one in your closet.

How it differs from a full-relay peer

An ordinary full-relay peer exchanges three kinds of gossip: transactions heading for the mempool, peer addresses, and blocks. A block-relay-only peer exchanges blocks and nothing else. By default a node maintains two such connections in addition to its eight full-relay outbound peers. The critical property is invisibility. Because these peers never learn about your transactions and never receive your node's address gossip, an observer mapping the network through the public transaction-relay graph cannot easily detect that the link exists. Your node's true connectivity is therefore larger than what any surveillance of transaction propagation would reveal.

Why it strengthens your node

That hidden margin is precisely the point. An eclipse attack works by learning or controlling all of a victim's connections, then feeding it a false view of the chain — the classic setup for double-spending against a merchant or splitting a miner from the honest network. If an adversary cannot enumerate your peers, it cannot reliably capture all of them. Block-relay-only connections guarantee that even if your visible transaction-relay peers were all compromised, blocks still arrive from an independent, unobserved set of nodes, so you cannot be silently held on a stale or fabricated tip. They raise the cost of partitioning attacks from "watch and target" to "control the victim's entire view of the address space," a dramatically harder problem. The design also costs almost nothing: block-only links skip transaction traffic, so their bandwidth overhead is minimal.

What a node runner should know

There is nothing to configure — the connections open automatically, and that is exactly how a good default should work. Where they become visible is in diagnostics: peer listings in Bitcoin Core will show connections of type block-relay-only, and understanding why they exist stops you from "fixing" them. On restart, the node attempts to reconnect to its previous block-relay-only peers first via the anchor connection mechanism, denying an attacker the chance to slot in fresh malicious peers during the vulnerable moments after a reboot. For anyone running a node to verify their own money — or to feed accurate templates to their own miner — this is one of several quiet mechanisms that make the answer trustworthy, alongside broader eclipse-attack resistance measures.

Limits worth knowing

Block-relay-only connections are a complement, not a substitute. Because they carry no transaction gossip, they contribute nothing to your view of the mempool — fee estimation, transaction monitoring, and relay of your own transactions all still depend on full-relay peers. They also do not anonymize anything by themselves; they simply refuse to leak topology through the transaction graph. And the protection is probabilistic, not absolute: an adversary with enough vantage points on the network can still attempt correlation through timing. The design philosophy is defense in depth — each mechanism removes one class of cheap attack. For miners the stakes are concrete: a node eclipsed onto a stale tip produces stale work, and every share mined on it is wasted. Two quiet block-only links to independent peers are among the cheapest insurance the network stack offers against handing an attacker that lever — and they are already running, unnoticed, on every up-to-date node that verifies your coins or feeds templates to your machines.