<p>First, let me clarify that the Erebus attack does <em>not</em> require rebooting the victim. It is only for speeding up the attack process. The attacker can patiently wait for the existing legitimate connections to expire and occupy them.</p>

<p>Coming back to your question, I guess you suggested to prioritize reconnecting the <em>current</em> outbound peers among all tried IPs. 
It actually doesn't help much because: 1) the victim may reconnect to shadow IPs controlled by the attacker and 2) again, the attacker can wait for legitimate connections to expire.</p>

<p>The bottom line here is that, because Bitcoin is permissionless, you may not be able to know which are good peers and bad peers to reconnect to. If a node strongly trusts some peers, it can simply whitelist them. But overall whitelisting is bad for decentralization.</p>

CC BY-SA 4.0
2019-08-19T04:14:39.080Z
2019-08-19T04:14:39.080Z
Muoi Tran
<p>They do attempt to reconnect to previous peers. Each node maintains a database in the <code>peers.dat</code> file of all the peers it has seen, along with whether they are reliable or not.</p>

<p>Once connected to some peers (whether by reconnecting to previously seen ones, or peers source from the dnsseeds), a node will also constantly exchange peer information with other peers, so that they can discover additional new/unseen nodes as they show up.</p>

CC BY-SA 4.0
2019-08-17T12:13:55.197Z
2019-08-17T12:13:55.197Z
Raghav Sood
<p>The <a href="http://erebus-attack.comp.nus.edu.sg" rel="nofollow noreferrer">Erebus attack</a> can, according to the authors, be accelerated by causing the victim node to reboot<sup>*</sup> at opportune moments. This is because the node will pick new outbound peers from a list that's been compromised by the attack.</p>

<p>What's the reason nodes don't frequently store their current outbound peers to disk and reconnect at restart?</p>

<p><sup>*</sup> by causing it to crash, which nodes are hardened against as much as possible </p>

<p2p>
Why don't nodes resume all existing outbound connections at restart?
Sjors Provoost
# Why don't nodes resume all existing outbound connections at restart?

(Asked by: username_0 on 2019-08-17)

The [Erebus attack](http://erebus-attack.comp.nus.edu.sg) can, according to the authors, be accelerated by causing the victim node to reboot\* at opportune moments. This is because the node will pick new outbound peers from a list that's been compromised by the attack.

What's the reason nodes don't frequently store their current outbound peers to disk and reconnect at restart?

\* by causing it to crash, which nodes are hardened against as much as possible

**Tags:** p2p


---

## 2 answers

### Answer by username_1 on 2019-08-19. Score: 4

First, let me clarify that the Erebus attack does *not* require rebooting the victim. It is only for speeding up the attack process. The attacker can patiently wait for the existing legitimate connections to expire and occupy them.

Coming back to your question, I guess you suggested to prioritize reconnecting the *current* outbound peers among all tried IPs.
It actually doesn't help much because: 1) the victim may reconnect to shadow IPs controlled by the attacker and 2) again, the attacker can wait for legitimate connections to expire.

The bottom line here is that, because Bitcoin is permissionless, you may not be able to know which are good peers and bad peers to reconnect to. If a node strongly trusts some peers, it can simply whitelist them. But overall whitelisting is bad for decentralization.


---

### Answer by username_2 on 2019-08-17. Score: 1

They do attempt to reconnect to previous peers. Each node maintains a database in the `peers.dat` file of all the peers it has seen, along with whether they are reliable or not.

Once connected to some peers (whether by reconnecting to previously seen ones, or peers source from the dnsseeds), a node will also constantly exchange peer information with other peers, so that they can discover additional new/unseen nodes as they show up.


---

