<div dir="ltr">Hi,<div><br></div><div>you good people do still have a VM on its own ipV4 sat twiddling its thumbs. It is pencilled in to be a 2nd relay for beta testing on. If you'd like to put it to a different use, please feel more than free to ask.</div>
<div><br></div><div>Regards,</div><div><br></div><div>Phill.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 28 October 2013 16:53, Nick Mathewson <span dir="ltr"><<a href="mailto:nickm@alum.mit.edu" target="_blank">nickm@alum.mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Oct 28, 2013 at 9:19 AM, Matthew Finkel<br>
<<a href="mailto:matthew.finkel@gmail.com">matthew.finkel@gmail.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
> This is a proposal I wrote to implement scalable hidden services. It's<br>
> by no means finished (there are some slight inconsistencies which I will<br>
> be correcting later today or tomorrow) but I want to make it public in<br>
> the meantime. I'm also working on some additional security measures that<br>
> can be used, but those haven't been written yet.<br>
><br>
> Many thanks to George for his initial feedback. I pushed this version to<br>
> my public repo, and will continue to push updates there.<br>
><br>
> In reality this is really 3.2 proposals, so the end result, if accepted,<br>
> will look significantly different, but I'm indecisive at this point<br>
> about which of the designs is least dangerous.<br>
<br>
</div></div>Looks cool!<br>
<br>
Generally, I think that requiring a single node to be master is fine<br>
in initial designs only: if we consider such a design, it's important<br>
to have a migration path to a design where the whole service doesn't<br>
fall over when a single leader goes down.  It's less important to me<br>
that there be no master key, especially if that master key can be kept<br>
offline.<br>
<br>
I also like designs where it's not immediately obvious how many hosts<br>
a hidden service has just from looking at its descriptor.<br>
<br>
<br>
FWIW, I'm working on a complete revision to rend-spec.txt, since I<br>
think the scope of hidden service changes under consideration is broad<br>
enough that it makes sense to reconsider the entire system as a whole<br>
rather than trying to do it one piece at a time.  I haven't even<br>
gotten to the spec parts yet -- just the preliminaries -- but you can<br>
see the draft in progress as it was on my desktop this morning in<br>
branch "rendspec-ng" in my torspec repo.  I'll be putting more updates<br>
there as I go.<br>
<br>
I mention that here because some of the design work I'm recording<br>
there should mitigate the dangers of distributing keys to different<br>
hosts.<br>
<br>
yrs,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Nick<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="https://wiki.ubuntu.com/phillw" target="_blank">https://wiki.ubuntu.com/phillw</a>
</div>