[tor-dev] Per-peer stream isolation for Bitcoin clients

[s7r]

Roger Dingledine wrote:
> On Fri, Jun 28, 2019 at 07:53:54AM +1000, teor wrote:
>> And you're right, Tor Browser can use lots more than 8 circuits, so
>> I wouldn't worry about it.
>>
>> Do you know how much load Bitcoin places on the Tor network?
>>
>> If it's a lot, one good answer is to encourage users to run relays,
>> or to donate to organisations that run relays. (Or donate to Tor,
>> so we can make the network more efficient.)
> 
> Right -- my first question would be "8 circuits per what?" That is,
> how often does it use eight new circuits?
> 
> If it makes 8 circuits and then holds them open and uses each of them
> for a long period of time, that sounds like a solid win -- you get
> isolation between streams with little downside.
> 
> If we're talking 8 circuits per new gadget, and the new gadgets are
> pretty frequent, then the tradeoff becomes more complicated.
> 
> --Roger
> 

It would hold on for the circuits until the peers on the other side of
each circuit disconnect or disappear. Usually Bitcoin full nodes are
steady and kept up (no recent disconnects of any sort, unless the peer
is unreliable).

But this is not the proper way to use Bitcoin behind Tor. So stream
isolation for clearnet type circuits shouldn't even be a concern.
Whonix's tor-service-defaults-torrc chooses to disable automatic
per-peer stream isolation for Bitcoin's SOCKS port and I think it does
the right thing, because this is not how Bitcoin should be used behind Tor.

Jeremy, when Bitcoin (Core) is used with Tor, the proper and recommended
way is to set in bitcoin.conf `onion=127.0.0.1:9050` (substitute with
the SocksPort of your system's Tor instance). This will teach Bitcoin
that we are behind Tor, so it should prefer .onion peers instead, this
way you won't be dependent on clearnet type circuits, and one (or 8)
exit nodes seeing all your peers or tampering with them. Bitcoin has 3
peer families:

-IPv4
-IPv6
-Tor (onion)

There is even a bitcoin option to make it ONLY connect to .onion peers:
`onlynet=tor`. This will eliminate Exit nodes out of the equation
entirely. There are lots of .onion peers. I run 3 (but there are many
more) "hybrid bridges", like nodes open to all 3 peer families so that
there .onion peers and clearnet peers are very well connected and synced
and the effect of "isolation/island" is not created.

It's of course desirable to prefer .onion peers while behind Tor.
Otherwise the peers will see one Exit node IP address as 'too many
peers' and give it bad score, as Bitcoin keeps a score for the
reliability overall of each peer, so you can understand it's quite
problematic for many "different peers" to connect to a peer with same IP
address.

Of course when more peers connect to your .onion, you still technically
see one remote IP address (127.0.0.1) but at least this is coded as Tor
and behaves differently than the score system for clearnet IP addresses.
Also .onion traffic is end-to-end encrypted and self-authenticated so
you eliminate the MITM attack type (given Bitcoin peer to peer traffic
is not encrypted). You are not forced to also listen on a .onion if you
use `onlynet=tor`, you can set `listenonion=0` -- you can play with it
how you want: connect to one or more families (any combination) and
listen to one or more families (any combination) or don't listen at all.
There's also an option where you can set the hostname like
`externalip=<hostname>.onion`, etc.

(re. teor): The Bitcoin traffic in Tor network / onion land is not
negligible. Look at just one of my bridge nodes:

Jun 27 17:05:51.000 [notice] Heartbeat: Tor's uptime is 15 days 6:00
hours, with 34 circuits open. I've sent 19.65 GB and received 5.70 GB.

There is only Bitcoin traffic here because there's nothing else. As you
can see we sent more than 3x what we received, meaning we helped more
nodes to bootstrap the blockchain (new started nodes or nodes that are
not kept on / connected 24x24).

So yeah, it would be nice to encourage the community towards running or
sponsoring relays to assist in maintaining a good capacity and diversity
of the Tor network, it is very important and widely used as you can see.

Also there is a ticket open by me:
https://github.com/bitcoin/bitcoin/issues/9214

to support v3 onion address types. Currently Bitcoin Core only supports
v2 legacy onion addresses, which are heavier on the network because use
TAP handshake and etc. v3 onion new address types are superior of
course, so getting this fixed will decrease the load on the Tor network
and increase the efficiency in Bitcoin onionland. Better work on this.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190628/deeef04d/attachment.sig>