<p>Block relay connections were added to bitcoin core in <a href="https://bitcoin.org/en/release/v0.19.0.1#p2p-changes" rel="noreferrer">v0.19.0.1</a> in November 2019. Their purpose is to harden the peer-to-peer network against partition attacks. They do this through a clever combination of factors:</p>
<p><strong>Protection from Network Topology Information Leaks</strong></p>
<p>A bitcoind node will not gossip address or transaction information over a <strong>block-relay-only</strong> connection. This prevents the node from leaking network topology information. A network topology map can be dangerous for two reasons:</p>
<ul>
<li>It can be used to trace the origin IP of a bitcoin transaction.</li>
<li>It can be used to perform an eclipse attack.</li>
</ul>
<p><strong>Increase Outbound Connections Without Significantly Increasing Network Traffic</strong></p>
<p>Address and transaction gossip messages make up the majority of a node's network bandwidth consumption. So adding additional outbound connections that do not gossip these messages allows for a more tightly integrated network graph with a very limited impact on the bandwidth required to run a node.</p>
<p><strong>Anchor Nodes</strong></p>
<p>Normally, a bitcoin node will connect to random peers upon startup. An anchor connection is an outbound node connection that persists across a restart. <strong>Block-relay-only</strong> connections were converted to anchor connections in <a href="https://bitcoincore.org/en/releases/0.21.0/" rel="noreferrer">v0.21.0</a> released in January 2021.</p>
<p>Anchor connections protect from a remote restart attack, which is the most likely vector of an eclipse attack. The attack works like this:</p>
<ul>
<li>Flood the target node's address manager with malicious node addresses.</li>
<li>Use some other exploit to force the target node to restart (or wait for a software upgrade). This tricks the target node into clearing its outbound connections and connecting only to malicious nodes.</li>
</ul>
<p>Too many anchor nodes can be a bad thing because it will entrench a malicious node connection and make it difficult for a node to defend or recover from an eclipse attack. They can also make the network topology graph more static, and therefore easier to map and easier to partition. But you definitely want to have a few anchor nodes to protect from remote restart eclipse attacks with some redundancy. Using <strong>block-relay-only</strong> connections as anchor connections strikes a nice balance in this regard. This configuration also benefits from the fact that <strong>block-relay-only</strong> connections are difficult for an attacker to detect due to their lack of ADDR and TX messages.</p>
<p>Anchor connections harden the peer-to-peer network using the &quot;one honest peer&quot; principle. As long as a bitcoin node is connected to one honest peer it will be able to stay informed about the chain of valid blocks with the greatest total proof of work. The node is able to rely on the unforgeable costliness of proof of work as the ultimate security guarantee. This, in turn, depends on an attacker not gaining control of a majority of the hashpower on the network. To put it succinctly, <strong>block-only-relay</strong> nodes bind the peer-to-peer security model more closely to the proof of work security model.</p>
<p><strong>Additional Resources</strong></p>
<ul>
<li><a href="https://github.com/bitcoin/bitcoin/pull/15759" rel="noreferrer">block-relay-only PR</a></li>
<li><a href="https://github.com/bitcoin/bitcoin/pull/17428" rel="noreferrer">anchor node PR</a></li>
<li><a href="https://github.com/bitcoin/bitcoin/issues/22370#issuecomment-870824597" rel="noreferrer">sipa comment on block-relay connections</a></li>
</ul>

CC BY-SA 4.0
2022-03-10T19:07:46.050Z
2022-03-12T17:41:46.213Z
2022-03-12T17:41:46.213Z
vnprc
<p>Modern versions of bitcoin core establish a fixed number of outbound connections: 8 <strong>outbound-full-relay</strong> connections and 2 <strong>block-relay-only</strong> connections. What is the purpose of <strong>block-relay-only</strong> connections and how are they used?</p>
<p>Here are two example log entries of a node establishing these connections:</p>
<pre><code>2022-03-10T14:50:36Z New outbound peer connected: version: 70015, blocks=726709, peer=1566 (outbound-full-relay)
2022-03-10T14:55:28Z New outbound peer connected: version: 70016, blocks=726710, peer=1576 (block-relay-only)
</code></pre>
<p>Here is an example CLI query showing all connected peers:</p>
<pre><code>$ bitcoin-cli -netinfo
Bitcoin Core v22.0.0 - 70016/Satoshi:22.0.0/

            ipv4    ipv6   onion   total   block  manual
    in         0       0      24      24
    out        2       0       9      11       2       1
    total      2       0      33      35

Local addresses
REDACTED     port   8333    score      4
</code></pre>
<p>Note: this node has one <code>addnode</code> entry in its <code>bitcoin.conf</code> file. Nodes connected to in this fashion do not count against the 8 and 2 outbound connection limits so this adds an additional 11th outbound peer.</p>

<network><attack><peers><peer-discovery><eclipse-attack>
What is a block-relay-only connection? What is it used for?
vnprc
# What is a block-relay-only connection? What is it used for?

(Asked by: username_0 on 2022-03-10)

Modern versions of bitcoin core establish a fixed number of outbound connections: 8 **outbound-full-relay** connections and 2 **block-relay-only** connections. What is the purpose of **block-relay-only** connections and how are they used?

Here are two example log entries of a node establishing these connections:

```
2022-03-10T14:50:36Z New outbound peer connected: version: 70015, blocks=726709, peer=1566 (outbound-full-relay)
2022-03-10T14:55:28Z New outbound peer connected: version: 70016, blocks=726710, peer=1576 (block-relay-only)

```

Here is an example CLI query showing all connected peers:

```
$ bitcoin-cli -netinfo
Bitcoin Core v22.0.0 - 70016/Satoshi:22.0.0/

            ipv4    ipv6   onion   total   block  manual
    in         0       0      24      24
    out        2       0       9      11       2       1
    total      2       0      33      35

Local addresses
REDACTED     port   8333    score      4

```

Note: this node has one `addnode` entry in its `bitcoin.conf` file. Nodes connected to in this fashion do not count against the 8 and 2 outbound connection limits so this adds an additional 11th outbound peer.

**Tags:** network, attack, peers, peer-discovery, eclipse-attack


---

## 1 answers

### Answer by username_0 on 2022-03-10. Score: 8

Block relay connections were added to bitcoin core in [v0.19.0.1](https://bitcoin.org/en/release/v0.19.0.1#p2p-changes) in November 2019. Their purpose is to harden the peer-to-peer network against partition attacks. They do this through a clever combination of factors:

**Protection from Network Topology Information Leaks**

A bitcoind node will not gossip address or transaction information over a **block-relay-only** connection. This prevents the node from leaking network topology information. A network topology map can be dangerous for two reasons:

* It can be used to trace the origin IP of a bitcoin transaction.
* It can be used to perform an eclipse attack.

**Increase Outbound Connections Without Significantly Increasing Network Traffic**

Address and transaction gossip messages make up the majority of a node's network bandwidth consumption. So adding additional outbound connections that do not gossip these messages allows for a more tightly integrated network graph with a very limited impact on the bandwidth required to run a node.

**Anchor Nodes**

Normally, a bitcoin node will connect to random peers upon startup. An anchor connection is an outbound node connection that persists across a restart. **Block-relay-only** connections were converted to anchor connections in [v0.21.0](https://bitcoincore.org/en/releases/0.21.0/) released in January 2021.

Anchor connections protect from a remote restart attack, which is the most likely vector of an eclipse attack. The attack works like this:

* Flood the target node's address manager with malicious node addresses.
* Use some other exploit to force the target node to restart (or wait for a software upgrade). This tricks the target node into clearing its outbound connections and connecting only to malicious nodes.

Too many anchor nodes can be a bad thing because it will entrench a malicious node connection and make it difficult for a node to defend or recover from an eclipse attack. They can also make the network topology graph more static, and therefore easier to map and easier to partition. But you definitely want to have a few anchor nodes to protect from remote restart eclipse attacks with some redundancy. Using **block-relay-only** connections as anchor connections strikes a nice balance in this regard. This configuration also benefits from the fact that **block-relay-only** connections are difficult for an attacker to detect due to their lack of ADDR and TX messages.

Anchor connections harden the peer-to-peer network using the "one honest peer" principle. As long as a bitcoin node is connected to one honest peer it will be able to stay informed about the chain of valid blocks with the greatest total proof of work. The node is able to rely on the unforgeable costliness of proof of work as the ultimate security guarantee. This, in turn, depends on an attacker not gaining control of a majority of the hashpower on the network. To put it succinctly, **block-only-relay** nodes bind the peer-to-peer security model more closely to the proof of work security model.

**Additional Resources**

* [block-relay-only PR](https://github.com/bitcoin/bitcoin/pull/15759)
* [anchor node PR](https://github.com/bitcoin/bitcoin/pull/17428)
* [sipa comment on block-relay connections](https://github.com/bitcoin/bitcoin/issues/22370#issuecomment-870824597)


---

