Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#30558: Namecoin support for onion sites in Tor Browser
--------------------------------------+--------------------------------
 Reporter:  arthuredelstein           |          Owner:  JeremyRand
     Type:  defect                    |         Status:  needs_revision
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  TorBrowserTeam201912      |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:  gk                        |        Sponsor:
--------------------------------------+--------------------------------

Comment (by JeremyRand):

 @gk Okay, so it was pretty easy to fix the issue where Ctrl+C didn't shut
 down Namecoin.  Just had to trap `SIGINT` in `start-tor-browser` to
 terminate the Namecoin processes.  Thanks for catching that.  Before I
 push a fix to a new branch, are there any other signals I should trap
 besides `SIGINT` (so that Namecoin gets shut down properly)?  I'm thinking
 `SIGTERM` would also be a good idea.  Any others I'm missing?

 Regarding the `STREAM` events that are showing up in your log: upstream
 Electrum periodically tries to reconnect to servers if they're down or got
 disconnected.  I'm pretty sure that's what's happening here; the ElectrumX
 server at `ulrichard.ch` is down for maintenance at the moment, and I
 think Electrum-NMC is trying periodically to connect to it in case it's
 come back up.  I'll look at the relevant code shortly and figure out
 whether there's a way we can reduce the impact this has.  That said, some
 initial thoughts:

 * Not reconnecting periodically at all will have bad effects, because
 Electrum-NMC launches before Tor has connected, so all the ElectrumX
 servers will appear to be unreachable when Electrum-NMC initially
 launches.
 * The above condition is probably fairly easy to detect, because *none* of
 the servers will be currently connected when Tor isn't connected yet.  So
 we could plausibly make the reconnect frequency high when no servers are
 connected, but much lower when at least 1 server is already connected.
 * We could also lower the reconnect frequency for a given server if that
 server has failed to connect multiple times while at least 1 other server
 was connected.  This might help us distinguish between a server failing to
 connect due to a bad Tor circuit versus a server failing to connect
 because the server is actually unreachable.
 * I'm not sure what lower reconnect frequency we should fall back to when
 at least 1 connection is already established and a given server has been
 unreachable multiple times.  There's a tradeoff here, because more server
 connections means it's less likely that we'll be fed a bad blockchain, but
 connecting too aggressively will put more load on the Tor network.
 * I'm honestly not sure why upstream Electrum is so aggressive at
 reconnecting (or if maybe I accidentally made it more aggressive while
 patching the network code for Namecoin/Tor purposes)... depending on what
 fixes we go with here, I might submit them upstream to Electrum too.

 Curious what your take is on the above suggested changes, or if you think
 there's some other approach I should look into.

 (FWIW, I can't reproduce the original issue where the domains were
 unreachable.  But let's come back to that after we've got the other issues
 dealt with.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30558#comment:52>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs