Bitcoin Forum

Hi guys,

I just stumbled across this paper (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1054.9020&rep=rep1&type=pdf (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1054.9020&rep=rep1&type=pdf)), which talks about huge vulnerabilities encountered when running a Bitcoin node over Tor.


What do you guys think?

I'm tossing up whether to continue using Tor or switch back to clearnet.

The paper says that running Tor and clearnet together mitigates the attack so just so that. Other short-term solutions I can think of:

- "Glitch" the address buckets - randomly drop addresses from the bucket on an hourly interval even when they are not full.
- Require all peers to submit their block height block hash of their longest tip, and ban nodes that don't have info that matches what is stored locally.
- glitch the banlist by randomly deleting some banned peers which weren't added manually.
- Reply to GETADDR messages with randomized ADDR messages that changes on each request.

Still reading, but I found this...

That misconception will never die.

I think we fall into the trap that Tor automatically makes everything better, when it doesn't. Basically, when ever you add another layer to your security, there's the potential problem of introducing a new layer of attack. For example, there's some real concerns about privacy when it comes to Tor. That's been well documented, and actually made it to mainstream tv shows, but we still automatically assume Tor is safe.

The real question is your threat model though. Since, running Tor also removes some of the problems of running it without Tor. It would probably take too long to go through everything that could potentially be compromised from doing one or the other. So, it's really up to the user themselves to decide what's better from a individual perspective.

Can you explain for the noobs?

---

So are you saying I just allow my node to connect on both clearnet and Tor, or create two separate nodes and some method of comparing the respective states, as suggested in the paper?

Thanks for all your suggestions. Unfortunately I'm not super tech savvy and so I imagine these will be beyond my ability to integrate.

[moderator's note: consecutive posts merged]

I feel like the more TOR grows the less of an attack vector this is. If Bitcoin was running over TOR by default and all users running core software were also acting as TOR exit nodes, I don’t realistically see this being a major concern. At present though, sure. TOR doesn’t have enough participants to make it decentralized enough to secure something like the Bitcoin network.

No you don't need to run two nodes.

By default, when you start Bitcoin Core, it tries to connect via IPV4, IPV6, and if you configured a Tor proxy (which you seemed to have done already), by Tor as well. There is no special configuration that you need to make to make your node attack-proof. You're only theoretically at risk if you have onlynet=tor in your config file or command line.

It is well known that some 3L3tter agencies are running several Tor exit nodes ...so it is a great vulnerability to run a node over Tor, but it is still more secure than running it over a public network.  ::)

We should take some precautions to protect our "nodes" .... but nothing is 100% secure in a world where attacks are coming from highly trained and skilled people that knows almost all exploits in the system. ( A lot of those attacks are government sanctioned)  ::)

In short people are confusing a "smaller than or equal to comparison" with "counting number of zeros".

In bitcoin's PoW, after the hash is computed it is compared with the 256 bit target as an integer and if the integer representation of the hash was smaller than or equal to the target then it is a valid hash, otherwise it is rejected.

If we count zeros we could accept a wrong hash or reject a valid one.
For example assuming we only have 4 bits (instead of 256) and hash is 0101 (5), it is smaller than 0110 (6) and bigger than 0100 (4) but all three values start with the same number of zeros (1 zero in 4 bit representation). If the target were 0100 and you accept 0101 because it has the same number of starting zeros that is invalid hash and the block is rejected.

That paper wasn't particularly correct when it was written--  essentially it's saying that a bad guy could dos attack all hidden service bitcoin peers AND make all clearnet peers ban all the tor peers.  And thus cause the tor using user to drop the protection of tor.  Okay, that used to be a concern but (1) the latter attack would have been highly visible and never happened and (2) "here is this benefit that DOS attacks might make you turn off" isn't a reason to not use the beneficial thing to begin with!

But worse, its completely inapplicable now -- and for many years -- because the banning mechanism they're discussing was removed.

But hey, every time I see someone promoting it I get extra information on which users are slightly more likely to be state actors trying to undermine the privacy of Bitcoin users.  So at least it has that benefit.

Kinda sucks though that bitcoiners don't even know that it's totally inapplicable and these same FUD threads keep getting repeated year after year and people that probably heard the correction don't remember.

Someone should probably put together a website with a list of links to papers like the OP posted, a one or 2 line summary of what it says, and then a link to an article / post / document as to why it is wrong.

So, when someone comes and does post about it again, all someone else has to do is say no, that's wrong here is why and here is the link.

Just saves time, and discussion and so on.

-Dave

Is the attack similar to Sybil attack, wherein the attacker handles multiple IP addresses and effectively "surrounds" a Bitcoin node? Doesn't this require computational power as well?

This is obviously incorrect. There's nothing preventing Tor nodes from accepting incoming connections.

Tor is the largest anonymity-preserving network at the moment.

Storing any significant amount of bitcoin on any device, using any browser is stupid. I don’t care what privacy you supposedly think you have. Don’t use a VPN either. My stash is in deep, fucking cold storage, you’d have to torture me to get my seeds/passphrases.

Seriously, you are never safe browsing if you store bitcoin on the device you browse with.

Stay smart & HODL.

What always bothered me about Tor is that there is not real incentive to be a node.

Yet, at the same, being a node requires many resources. Among them, you better have an ISP that's going to be lenient over all the crazy stuff that's going to go through your node!

As such, nodes are often run by intelligence agencies. :(

It's why I don't really trust Tor...

There's the same incentive as with running a Bitcoin node: privacy. Whenever you use Tor to browse the internet privately, you're a node that relays traffic. That's why the more Tor users the better. You can use Nyx (https://nyx.torproject.org/) to see to whom you send information, by whom do you receive it, and other general bandwidth info.

What you must have meant is an incentive to run an exit node. Not only doesn't there be an incentive, but there's actually a disincentive, because IP addresses from exit nodes are not welcomed in some sites. That's why there are very few: https://tor.stackexchange.com/questions/646/why-are-there-only-1000-exit-relays/

The same goes for the dark/deep web. They want all the illegal activities to happen there so they can catch them all in one swoop. Just don't say or do anything online which you wouldn't do in your real life and you will be fine. As far as I am concerned TOR or any other stuff are only good for accessing information/websites which are blocked in your country. Some countries block porn websites too and it comes in handy in those situations too but I would never ever purchase drugs via TOR. I'd rather buy a ticket and visit the Netherlands instead.

The only way to be caught in such site is if it isn't run by criminals but by actual agents as a honeypot, or if you're demanded to hand over personal information that might end up to the agents. Getting caught by de-anonymizing onion routing is the government's last course as it most of the times requires coordination with other nations. This attack is known as "correlation attack (https://tor.stackexchange.com/a/116/37175)". It becomes even more difficult to de-anonymize if it's a hidden service.

You shouldn't, not because you might get caught, but because 99% of these sites are scam.

You are a correct: I meant exit node.

Regular Tor users won't automatically act as a relay. That scenario is one of the alternative possible designs (https://support.torproject.org/alternate-designs/#make-every-user-a-relay), but as of now, it does not.


Less exit node on the Tor network is very likely caused due to how the operator could get legal risk and exposure.

Weird, because whenever I have Tor Browser opened, it does have an uploading and downloading bandwidth. Indeed, from nyx I can see that it has relaying disabled:


That's with just one window, at the main "most private browsing experience" page. I presume these bytes transferred are like heartbeats?

I believe it is just a regular internet traffic graph over Tor.


It could be reachability test or circuit build process. If you slide next to Connections page in nyx you will see that there are already Tor circuits and the one that is still being built("Building..."). The "heartbeats" you talk could be the process of building it or checking the circuit timeout[1].

[1] https://tor.stackexchange.com/a/4636