> On 6 Dec. 2016, at 07:42, David Goulet <[email protected]> wrote: > > On 22 Nov (17:36:33), David Goulet wrote: >> Hi everyone! >> >> We are soon at the stage of implementing the service part of proposal 224 >> (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing >> here ticket #18054. >> >> In a nutshell, we need to figure out the interface for the torrc file[1]. We >> currently have some options to configure an hidden service and the question >> is >> now how do we proceed on using those for next version? > > [snip] > > (Please read original email for some initial context.) > > So over the last week, we've mashed up all the things that were said in this > thread, me and asn discussed it with some arma also on the side! > > I think the following is the best of all the non ideal solutions we can come > up with. Below is a superb ascii timeline of what we plan to do in terms of > transition from v2 to v3: > > > Our dystopian reality of now. > (https://youtu.be/NrmMk1Myrxc > it's not a Black Mirror SO3 trailer) > v > | ~Aug '17 ~Dec '17 Unknown date > |-----------------|-----------------|----------------|----------> > | ^ ^ > ^ v3 Network/Code | > tor stable release Maturity | > with v3 support No more v2 > (0.3.1) > > Ok, might not be my best ascii art work but I hope it will do. In short: > > - With 0.3.1 (scheduled for August 2017, subject to change), we'll have a tor > with v3 support BUT v2 will still be the default value for *new* HS. > (HiddenServiceVersion option) > > - For a period of ~4 months we estimate, we'll hope that enough of the network > has upgraded to support v3 (relay and HSDir support are in 030) and that the > code as some sort of maturity that we are confident to switch and make all > new HS be v3. This is the "v3 Network/Code Maturity" marker. Note that it > could easily go to 2018 for this switch to happen. > > - When the switch happens, there will be, most likely years, a long period of > time where v2 will be deprecated and warnings given to users but still used. > That "Unknown date" will be the time we will release a tor stable version > _without_ v2 support at all. It's quite unknown when we'll be able to do it. > Chances are that we'll rely on our HS statistics and metrics for that. > > That being said, here are the conclusions based on this thread and f2f > discussion considering the above "procedure": > > 1) When v3 is released in a tor stable version, it will NOT be the default > version for new service, v2 will until maturity. > > 2) HiddenServiceVersion is used to control which version of the service you > want. Starting from the first time v3 is supported, you'll be able to use > it but without any guarantee as we'll be entering the "stabilizing period" > but it should be usable. > > 3) ADD_ONION "BEST" will map to whatever default value HiddenServiceVersion is > with the tor you have. > > 4) In order to avoid relying on a tor stable version release to switch the > default version from 2 to 3, we'll use a consensus parameter. Meaning that > once we set that param. to v3, HiddenServiceVersion default value will be > that value unless explicitely defined in torrc. It will also allow us to > rollback to v2 if we see a swarm of badness occuring. To be clear, service > already v3 will stay v3 but the default version for creation will simply > change. > ...
This is problematic: we validate and create onion services at torrc load, before loading the consensus. Do we plan to do it afterwards? That seems like it could be really confusing. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
