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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev