5

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!

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.