<p>There's no handling of this really. The incoming connection just appears to be from localhost, <code>bitcoind</code> has absolutely no way of even identifying what circuit they came from. Banning them becomes a nothing or everything affair. It would be extremely unwise to act in the way that you have defined, especially given that at this time there are less than 50 connectable peers, and there's no guarantee they aren't all run by the same operator. </p>

<p>Realistically Bitcoin has very little defense against any meaningful denial of service attacks. It is very vulnerable to volumetric, protocol level (especially prior to the removal of BIP37), and resource exhaustion attacks by even a relatively unfunded attacker, regardless of the network being used as a transport. </p>

CC BY-SA 4.0
2020-02-03T02:35:24.613Z
2020-02-03T02:35:24.613Z
Claris
<p>If I start <code>bitcoind</code> with settings <code>proxy=127.0.0.1:9050</code> to talk to the Tor daemon's SOCKS5 proxy, turn on <code>listenonion=1</code> and set <code>onlynet=onion</code>, my understanding is that <code>bitcoind</code> will coordinate with the Tor daemon to find a randomized onion public key/identifier and begin operating with other .onion peers.</p>

<p>However, what is stopping a Tor-connected onion node from behaving badly in a way that would 'normally' get the IPV4/V6 address banned had it been doing the same thing via that connection type?</p>

<p>It seems to me like a malicious node could just re-randomize the credentials on Tor to evade any ban. Does this mean that Tor nodes are less robust than the IPV4/V6 and more susceptible to DDoS and other attacks? or has this been accounted for somehow?</p>

<p>An explanation would be helpful. Thank you!</p>

<bitcoind><tor>
How does peer banning work for onion peers?
jd2983
# How does peer banning work for onion peers?

(Asked by: username_0 on 2020-02-02)

If I start `bitcoind` with settings `proxy=127.0.0.1:9050` to talk to the Tor daemon's SOCKS5 proxy, turn on `listenonion=1` and set `onlynet=onion`, my understanding is that `bitcoind` will coordinate with the Tor daemon to find a randomized onion public key/identifier and begin operating with other .onion peers.

However, what is stopping a Tor-connected onion node from behaving badly in a way that would 'normally' get the IPV4/V6 address banned had it been doing the same thing via that connection type?

It seems to me like a malicious node could just re-randomize the credentials on Tor to evade any ban. Does this mean that Tor nodes are less robust than the IPV4/V6 and more susceptible to DDoS and other attacks? or has this been accounted for somehow?

An explanation would be helpful. Thank you!

**Tags:** bitcoind, tor


---

## 1 answers

### Answer by username_1 on 2020-02-03. Score: 1

There's no handling of this really. The incoming connection just appears to be from localhost, `bitcoind` has absolutely no way of even identifying what circuit they came from. Banning them becomes a nothing or everything affair. It would be extremely unwise to act in the way that you have defined, especially given that at this time there are less than 50 connectable peers, and there's no guarantee they aren't all run by the same operator.

Realistically Bitcoin has very little defense against any meaningful denial of service attacks. It is very vulnerable to volumetric, protocol level (especially prior to the removal of BIP37), and resource exhaustion attacks by even a relatively unfunded attacker, regardless of the network being used as a transport.


---

