Hi Jeremy,

On 28 Jun 2019, at 06:35, Jeremy Rand <jeremyrand@airmail.cc> wrote:

2. Per-peer stream isolation prevents a single exit relay from feeding the user a chain that's not the longest chain, so it's desirable from a Bitcoin security point of view.

Tor itself uses 3 directory guards to make sure that one guard can't feed it bad data. If you use one exit, and it happens to be malicious, all your peers are accessed via that bad exit. But if you use 8 exits, then it's very unlikely that all of them will be malicious in exactly the same way. But it makes it 8x more likely that any one of your exits will be malicious. It's also worth using multiple circuits for redundancy, so a single exit can't deny service all 8 of your peers. (As noted on the pull request.) So it's a tradeoff, based on the protocol. For example: * If you were mainly worried about exploits, then you'd want one exit. * If you are worried about short chains or denial of service, then you'd want many exits. If you don't know which one to choose, follow Tor Browser, which uses many exits. (The right way to deal with exploits is to fix those bugs, and use coding practices that make them less likely.)

3. Per-peer stream isolation would mean more potential for one of the circuits being deanonymizable, via traffic analysis etc. It's not clear to me whether this amount of increased circuits is harmful, or how it compares to other common usage of Tor such as Tor Browser (which uses first-party stream isolation, so a user with a lot of tabs open may very well have 8 or more circuits in use at once).

It's not quite that simple: If you send traffic from all 8 peers over one circuit, then a pattern might be visible on you client to guard, and exit to internet connections. That pattern makes correlation easier. Using 8 circuits splits the traffic pattern across 8 different exit locations on the internet, so correlation is harder. I'd follow Tor Browser on this one, too.

4. Per-peer stream isolation puts more load on the Tor network. It's not clear to me whether this increased load (8 circuits instead of 1) is so much that it's harmful.

Every Tor client tries to keep 6+ pre-emptive circuits open, so that new requests have lower latency. So you're really looking at doubling your circuit load, not multiplying it by 8. Once the circuits are built, there's not much extra load splitting the streams across 8 circuits, because it's already split into streams and cells within the protocol. 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.) T

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.