[tor-dev] Reducing initial onion descriptor upload delay (down to 0s?)

Razvan Dragomirescu razvan.dragomirescu at veri.fi
Thu Sep 8 08:47:05 UTC 2016


I've just tried the patch from ticket 20082 and it works great for me. I
was actually wondering why it was taking so long for a ephemeral hidden
service to get registered in my SIM4Things project (I register an ephemeral
service first to get Tor to setup the introduction points, then re-register
it a la OnionBalance with a new identity). It's definitely a great
improvement for my project!

Razvan

On Wed, Sep 7, 2016 at 6:40 PM, Ivan Markin <twim at riseup.net> wrote:

> Hi tor-dev@!
>
> Moving the discussion on the future of rendinitialpostdelay from ticket
> #20082 [1] here.
>
> Transcribing the issue:
> > At the moment descriptor is getting posted at
> > MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service
> > initialization. For the use case of real-time one-time services
> > (like OnionShare, etc) one has to wait for 30 seconds until this
> > onion service can be reached. Besides, if a client tries to reach
> > the service before its descriptor is ever published, tor client gets
> > stuck preventing user from reaching this service after descriptor is
> > published. Like this: Could not pick one of the responsible hidden
> > service directories to fetch descriptors, because we already tried
> > them all unsuccessfully.
>
>
> > It has jumped to 30s from 5s due to "load on authorities".
> > 11d89141ac0ae0ff371e8da79abe218474e7365c:
> >
> > +  o Minor bugfixes (hidden services): +    - Upload hidden service
> > descriptors slightly less often, to reduce +      load on
> > authorities.
> >
> > "Load on authorities" is not the point anymore because we don't use
> > V0 since 0.2.2.1-alpha. Thus I think it's safe to drop it back to at
> > least 5s (3s?) for all services. Or even remove it at all?
>
> The questions are:
>   * Can we drop this delay? Why?
>   * Can we set it back to 5s thus avoiding issues that can arise after
> removing the delay?
>   * Should we do something now or postpone it to prop224?
>
> [1] https://trac.torproject.org/projects/tor/ticket/20082
> --
> Ivan Markin
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160908/dbf28c64/attachment-0001.html>


More information about the tor-dev mailing list