<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-11-20 17:24 GMT+01:00 <span dir="ltr"><<a href="mailto:tor-dev-request@lists.torproject.org" target="_blank">tor-dev-request@lists.torproject.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send tor-dev mailing list submissions to<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:tor-dev-request@lists.torproject.org">tor-dev-request@lists.torproject.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:tor-dev-owner@lists.torproject.org">tor-dev-owner@lists.torproject.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of tor-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Shared random value calculation edge cases (proposal 250)<br>
(George Kadianakis)<br>
2. Re: Shared random value calculation edge cases (proposal 250)<br>
(David Goulet)<br>
3. Re: Shared random value calculation edge cases (proposal 250)<br>
(David Goulet)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 20 Nov 2015 16:06:59 +0200<br>
From: George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>><br>
To: s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>><br>
Cc: <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
Subject: Re: [tor-dev] Shared random value calculation edge cases<br>
(proposal 250)<br>
Message-ID: <<a href="mailto:87fv0069z0.fsf@riseup.net">87fv0069z0.fsf@riseup.net</a>><br>
Content-Type: text/plain<br>
<br>
s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> writes:<br>
<br>
> Hello,<br>
><br>
> <snip><br>
><br>
> The idea of adding flags in the votes so each dirauth can advertise if<br>
> it is participating (has an opinion for the <current> SR or not) is<br>
> great and helps us build more defenses, probably make it easier in the<br>
> future too if we decide to change anything.<br>
><br>
> What if the consensus for SR calculation would define majority based<br>
> on dirauths actually participating (and advertising so with a flag in<br>
> the vote). Also, the participating or not participating flag should be<br>
> used per vote/consensus and split into:<br>
><br>
> a) we know current SR value for today so we vote it<br>
> or<br>
> we know previous SR value and we know for sure if we should follow the<br>
> disaster protocol or not (in case we are about to vote at 01:00 UTC).<br>
> so<br>
> We participate in the vote for <current SR>.<br>
><br>
> b) we are able to participate in this protocol run which will<br>
> calculate the SR value for next day (after 00:00 UTC) so we send our<br>
> commits/reveals.<br>
><br>
> This is useful in case we are a dirauth that joined at 00:30 UTC and<br>
> we couldn't get the _latest_ consensus (to find out if the 00:00 UTC<br>
> consensus was created, and if not, previous SR value so we can follow<br>
> the disaster procedure) we will not have an opinion for the <current><br>
> SR value at 01:00 UTC, but we can start participating in the protocol<br>
> run for the next day - send our commit values. Once we decided on a<br>
> <current> SR value for that day we save it and vote normally next time.<br>
><br>
> So, if we have 5 dirauths running/signing consensus in total, out of<br>
> which only 4 participate in the shared randomness protocol, the 4<br>
> participating ones should be able to create a valid consensus<br>
> themselves with the insurance that the 5th one won't break consensus.<br>
><br>
> One way to do this is: the dirauth which is not participating will<br>
> take the SR value voted by the majority of the participating dirauths<br>
> and include that in its consensus and sign. We need at least 3<br>
> dirauths agreeing on a SR value in order to accept it.<br>
><br>
> Is this crazy? It shouldn't open the door new attacks, since this<br>
> doesn't allow a single actor to game it, only the majority could game it.<br>
><br>
<br>
Thanks for the suggestions.<br>
<br>
Let me try to suggest a procedure here based on your ideas and some other ideas.<br>
<br>
[Notation: SRV = shared random value]<br>
<br>
The goal here is to minimize the edge cases during SRV calculation and disaster<br>
SRV calculation. The edge cases here appear because there is no clear view on<br>
whether other dirauths know the current or previous SRVs, or whether the SRV for<br>
this period was ever created. The disaster recovery scenario is especially<br>
annoying here.<br>
<br>
Here are some edge cases for example:<br>
<br>
* Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain any<br>
SR information (maybe because not enough SR-enabled dirauths participated at<br>
that time).<br>
<br>
Should the dirauth do the disaster recovery procedure, or just play it cool<br>
and put no SR information on the consensus? If it has to do disaster recovery,<br>
then what previous SRV does it use (the 01:00UTC consensus did not contain<br>
such info)?<br>
<br>
This type of edge case is my main concern, since with dirauths upgrading and<br>
going offline at random times, it's likely that we will eventually create a<br>
consensus without SR info in the middle of the protocol run.<br>
<br>
* Dirauth boots up at 23:55UTC without having a previous consensus. It is<br>
supposed to vote and form a 00:00UTC consensus without knowing any previous<br>
SRVs. How does it figure out whether all the other dirauths are also<br>
bootstrapping, or whether the other dirauths actually know the previous SRVs?<br>
<br>
Here are some prerequisites for the logic I'm going to suggest. The two first<br>
suggestions are useful in any case, I think:<br>
<br>
- First of all, we treat consensuses as trusted, so dirauths MUST learn<br>
previous/current SRVs they didn't know about from any consensus they fetch.<br>
<br>
- We are also going to assume that we have some sort of "SR flag" on votes to<br>
denote whether the dirauth participates in the protocol.<br>
<br>
- We are introducing another 'status' for shared random values (see [SRVOTE]).<br>
<br>
Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be<br>
created, or it did not contain any SRV information, then it sets the status of<br>
"shared-rand-current-value" in its votes to "none".<br>
<br>
Now we are going to use the SRV lines in the votes as an indicator on how the<br>
consensus creation should play out.<br>
<br>
================================================================================<br>
<br>
Here is some logic for the consensus at 00:00UTC:<br>
<br>
if majority of votes have disabled the SR flag:<br>
then don't write anything SR-related to consensus<br>
exit<br>
<br>
If the majority of votes contain the previous SRV value:<br>
then calculate SRV as detailed in section [SRCALC]<br>
else:<br>
then calculate SRV as in [SRCALC] but with previous_SRV set to 0<br>
<br>
And here is some logic for all the other consensuses (to figure out when<br>
dirauths should perform the disaster procedure):<br>
<br>
if majority of votes have disabled the SR flag:<br>
then don't write anything SR-related to consensus<br>
exit<br>
<br>
if we know the current SRV:<br>
then write it on the consensus<br>
exit<br>
<br>
if the majority of votes have the current SRV status as "none" _AND_<br>
those votes also contain the previous SRV value:<br>
then do the disaster SRV procedure<br>
else:<br>
then don't write anything SR-related to consensus<br>
<br>
================================================================================<br>
<br>
This _might_ work for fixing a good bunch of edge cases. But is it far too complex?<br>
<br>
Should we just assume that these things will never happen on the real network<br>
and avoid baking additional complexity? What do you think? :/<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 20 Nov 2015 10:19:07 -0500<br>
From: David Goulet <<a href="mailto:dgoulet@ev0ke.net">dgoulet@ev0ke.net</a>><br>
To: <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
Subject: Re: [tor-dev] Shared random value calculation edge cases<br>
(proposal 250)<br>
Message-ID: <20151120151907.GD10269@raoul><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On 20 Nov (16:06:59), George Kadianakis wrote:<br>
> s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> writes:<br>
><br>
> > Hello,<br>
> ><br>
> > <snip><br>
> ><br>
> > The idea of adding flags in the votes so each dirauth can advertise if<br>
> > it is participating (has an opinion for the <current> SR or not) is<br>
> > great and helps us build more defenses, probably make it easier in the<br>
> > future too if we decide to change anything.<br>
> ><br>
> > What if the consensus for SR calculation would define majority based<br>
> > on dirauths actually participating (and advertising so with a flag in<br>
> > the vote). Also, the participating or not participating flag should be<br>
> > used per vote/consensus and split into:<br>
> ><br>
> > a) we know current SR value for today so we vote it<br>
> > or<br>
> > we know previous SR value and we know for sure if we should follow the<br>
> > disaster protocol or not (in case we are about to vote at 01:00 UTC).<br>
> > so<br>
> > We participate in the vote for <current SR>.<br>
> ><br>
> > b) we are able to participate in this protocol run which will<br>
> > calculate the SR value for next day (after 00:00 UTC) so we send our<br>
> > commits/reveals.<br>
> ><br>
> > This is useful in case we are a dirauth that joined at 00:30 UTC and<br>
> > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC<br>
> > consensus was created, and if not, previous SR value so we can follow<br>
> > the disaster procedure) we will not have an opinion for the <current><br>
> > SR value at 01:00 UTC, but we can start participating in the protocol<br>
> > run for the next day - send our commit values. Once we decided on a<br>
> > <current> SR value for that day we save it and vote normally next time.<br>
> ><br>
> > So, if we have 5 dirauths running/signing consensus in total, out of<br>
> > which only 4 participate in the shared randomness protocol, the 4<br>
> > participating ones should be able to create a valid consensus<br>
> > themselves with the insurance that the 5th one won't break consensus.<br>
> ><br>
> > One way to do this is: the dirauth which is not participating will<br>
> > take the SR value voted by the majority of the participating dirauths<br>
> > and include that in its consensus and sign. We need at least 3<br>
> > dirauths agreeing on a SR value in order to accept it.<br>
> ><br>
> > Is this crazy? It shouldn't open the door new attacks, since this<br>
> > doesn't allow a single actor to game it, only the majority could game it.<br>
> ><br>
><br>
> Thanks for the suggestions.<br>
><br>
> Let me try to suggest a procedure here based on your ideas and some other ideas.<br>
><br>
> [Notation: SRV = shared random value]<br>
><br>
> The goal here is to minimize the edge cases during SRV calculation and disaster<br>
> SRV calculation. The edge cases here appear because there is no clear view on<br>
> whether other dirauths know the current or previous SRVs, or whether the SRV for<br>
> this period was ever created. The disaster recovery scenario is especially<br>
> annoying here.<br>
><br>
> Here are some edge cases for example:<br>
><br>
> * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain any<br>
> SR information (maybe because not enough SR-enabled dirauths participated at<br>
> that time).<br>
><br>
> Should the dirauth do the disaster recovery procedure, or just play it cool<br>
> and put no SR information on the consensus? If it has to do disaster recovery,<br>
> then what previous SRV does it use (the 01:00UTC consensus did not contain<br>
> such info)?<br>
><br>
> This type of edge case is my main concern, since with dirauths upgrading and<br>
> going offline at random times, it's likely that we will eventually create a<br>
> consensus without SR info in the middle of the protocol run.<br>
><br>
> * Dirauth boots up at 23:55UTC without having a previous consensus. It is<br>
> supposed to vote and form a 00:00UTC consensus without knowing any previous<br>
> SRVs. How does it figure out whether all the other dirauths are also<br>
> bootstrapping, or whether the other dirauths actually know the previous SRVs?<br>
><br>
> Here are some prerequisites for the logic I'm going to suggest. The two first<br>
> suggestions are useful in any case, I think:<br>
><br>
> - First of all, we treat consensuses as trusted, so dirauths MUST learn<br>
> previous/current SRVs they didn't know about from any consensus they fetch.<br>
<br>
Yes ++.<br>
<br>
A dirauth booting up should always try to learn the current and previous<br>
SRV from the latest consensus (< 24h) and update the disk state<br>
accordingly _even_ if the disk state has SRV values in there. We should<br>
trust the consensus voted by majority before our disk state imo.<br>
<br>
><br>
> - We are also going to assume that we have some sort of "SR flag" on votes to<br>
> denote whether the dirauth participates in the protocol.<br>
<br>
The requirements for having that flag "on" or "off" eludes me a bit. I<br>
assume that this SR flag is "on" when a dirauth thinks its able to<br>
compute a valid SRV that is I have enough commits. We can't make "having<br>
the previous SRV" a requirement else we will never bootstrap properly<br>
ever since in the first runs, previous SRV is alway 0.<br>
<br>
><br>
> - We are introducing another 'status' for shared random values (see [SRVOTE]).<br>
><br>
> Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be<br>
> created, or it did not contain any SRV information, then it sets the status of<br>
> "shared-rand-current-value" in its votes to "none".<br>
<br>
Hrm... I'm wondering here if "none" status is instead the same of having<br>
the dirauth putting the disaster value in the vote?<br>
<br>
I would argue that a dirauth should _always_ try to compute a SR value<br>
at any time (even when booting). Between having no line because we<br>
couldn't compute due to lack of commits or a line that is the disaster,<br>
I think the former simplifies things that is "We always have a SRV value<br>
at 00:00 from a dirauth".<br>
<br>
Here is what I propose:<br>
<br>
1) Like you said, we always try to learn SRV values from previous<br>
consensus. If we can't get one from a consensus or our state, compute<br>
disaster at 00:00.<br>
<br>
2) We do _not_ use a SR flag for vote, a dirauth always tries to compute<br>
a current SRV value at 00:00. If it's 13:00, it simply doesn't put<br>
anything in the vote since no SRV data.<br>
<br>
The big issue I see here is when a dirauth does _not_ have the previous<br>
SRV. Without it, both disaster and current SRV computation will end up<br>
not matching the majority. So let's explore this binary state:<br>
<br>
- I have the previous SRV (either I can get it from my state or<br>
consensus).<br>
<br>
This seems a non issue, dirauth will use it, carry it in the vote and<br>
compute the current SRV if enough commits have been seen. At 00:00, if<br>
majority wasn't reached for the current SRV value, we have a consensus<br>
without it which is a valid use case but we at least have the previous<br>
one in the consensus flagged as non-fresh so it can be used for<br>
disaster or SRV computation at the next protocol run.<br>
<br>
- I don't have a previous SRV (couldn't get it in the latest consensus<br>
and I have _no_ disk state).<br>
<br>
For instance, if this happens at 23:30, a dirauth won't have the<br>
chance to participate in the SR protocol because it didn't see any<br>
commits to compute SRV value thus disaster mode engage.<br>
<br>
If that dirauth was the 5th one out of 9 (meaning the majority<br>
breaker), we end up with no SRV values at all at 00:00 (not even the<br>
previous SRV since only 4/9 had it). So a new protocol run starts,<br>
we'll end up with a valid current SRV in 24 hours and both values in<br>
48 hours. Essentially, we end up back in bootstrap mode.<br>
<br>
IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values<br>
that aren't in the 00:00 consensus.<br>
<br>
Question is, how big of a deal it is to have this issue where if we<br>
don't reach majority because a dirauth rebooted and for some magical<br>
reason didn't get the latest consensus to at least get the previous<br>
SRV, we return in bootstrap?<br>
<br>
Cheers!<br>
David<br>
<br>
><br>
> Now we are going to use the SRV lines in the votes as an indicator on how the<br>
> consensus creation should play out.<br>
><br>
> ================================================================================<br>
><br>
> Here is some logic for the consensus at 00:00UTC:<br>
><br>
> if majority of votes have disabled the SR flag:<br>
> then don't write anything SR-related to consensus<br>
> exit<br>
><br>
> If the majority of votes contain the previous SRV value:<br>
> then calculate SRV as detailed in section [SRCALC]<br>
> else:<br>
> then calculate SRV as in [SRCALC] but with previous_SRV set to 0<br>
><br>
> And here is some logic for all the other consensuses (to figure out when<br>
> dirauths should perform the disaster procedure):<br>
><br>
> if majority of votes have disabled the SR flag:<br>
> then don't write anything SR-related to consensus<br>
> exit<br>
><br>
> if we know the current SRV:<br>
> then write it on the consensus<br>
> exit<br>
><br>
> if the majority of votes have the current SRV status as "none" _AND_<br>
> those votes also contain the previous SRV value:<br>
> then do the disaster SRV procedure<br>
> else:<br>
> then don't write anything SR-related to consensus<br>
><br>
> ================================================================================<br>
><br>
> This _might_ work for fixing a good bunch of edge cases. But is it far too complex?<br>
><br>
> Should we just assume that these things will never happen on the real network<br>
> and avoid baking additional complexity? What do you think? :/<br>
><br>
><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" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 603 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/c02f52ca/attachment-0001.sig" rel="noreferrer" target="_blank">http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/c02f52ca/attachment-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 20 Nov 2015 11:24:24 -0500<br>
From: David Goulet <<a href="mailto:dgoulet@ev0ke.net">dgoulet@ev0ke.net</a>><br>
To: <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
Subject: Re: [tor-dev] Shared random value calculation edge cases<br>
(proposal 250)<br>
Message-ID: <20151120162424.GE10269@raoul><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On 20 Nov (10:19:07), David Goulet wrote:<br>
> On 20 Nov (16:06:59), George Kadianakis wrote:<br>
> > s7r <<a href="mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> writes:<br>
> ><br>
> > > Hello,<br>
> > ><br>
> > > <snip><br>
> > ><br>
> > > The idea of adding flags in the votes so each dirauth can advertise if<br>
> > > it is participating (has an opinion for the <current> SR or not) is<br>
> > > great and helps us build more defenses, probably make it easier in the<br>
> > > future too if we decide to change anything.<br>
> > ><br>
> > > What if the consensus for SR calculation would define majority based<br>
> > > on dirauths actually participating (and advertising so with a flag in<br>
> > > the vote). Also, the participating or not participating flag should be<br>
> > > used per vote/consensus and split into:<br>
> > ><br>
> > > a) we know current SR value for today so we vote it<br>
> > > or<br>
> > > we know previous SR value and we know for sure if we should follow the<br>
> > > disaster protocol or not (in case we are about to vote at 01:00 UTC).<br>
> > > so<br>
> > > We participate in the vote for <current SR>.<br>
> > ><br>
> > > b) we are able to participate in this protocol run which will<br>
> > > calculate the SR value for next day (after 00:00 UTC) so we send our<br>
> > > commits/reveals.<br>
> > ><br>
> > > This is useful in case we are a dirauth that joined at 00:30 UTC and<br>
> > > we couldn't get the _latest_ consensus (to find out if the 00:00 UTC<br>
> > > consensus was created, and if not, previous SR value so we can follow<br>
> > > the disaster procedure) we will not have an opinion for the <current><br>
> > > SR value at 01:00 UTC, but we can start participating in the protocol<br>
> > > run for the next day - send our commit values. Once we decided on a<br>
> > > <current> SR value for that day we save it and vote normally next time.<br>
> > ><br>
> > > So, if we have 5 dirauths running/signing consensus in total, out of<br>
> > > which only 4 participate in the shared randomness protocol, the 4<br>
> > > participating ones should be able to create a valid consensus<br>
> > > themselves with the insurance that the 5th one won't break consensus.<br>
> > ><br>
> > > One way to do this is: the dirauth which is not participating will<br>
> > > take the SR value voted by the majority of the participating dirauths<br>
> > > and include that in its consensus and sign. We need at least 3<br>
> > > dirauths agreeing on a SR value in order to accept it.<br>
> > ><br>
> > > Is this crazy? It shouldn't open the door new attacks, since this<br>
> > > doesn't allow a single actor to game it, only the majority could game it.<br>
> > ><br>
> ><br>
> > Thanks for the suggestions.<br>
> ><br>
> > Let me try to suggest a procedure here based on your ideas and some other ideas.<br>
> ><br>
> > [Notation: SRV = shared random value]<br>
> ><br>
> > The goal here is to minimize the edge cases during SRV calculation and disaster<br>
> > SRV calculation. The edge cases here appear because there is no clear view on<br>
> > whether other dirauths know the current or previous SRVs, or whether the SRV for<br>
> > this period was ever created. The disaster recovery scenario is especially<br>
> > annoying here.<br>
> ><br>
> > Here are some edge cases for example:<br>
> ><br>
> > * Dirauth boots up at 02:00UTC and the 01:00UTC consensus does not contain any<br>
> > SR information (maybe because not enough SR-enabled dirauths participated at<br>
> > that time).<br>
> ><br>
> > Should the dirauth do the disaster recovery procedure, or just play it cool<br>
> > and put no SR information on the consensus? If it has to do disaster recovery,<br>
> > then what previous SRV does it use (the 01:00UTC consensus did not contain<br>
> > such info)?<br>
> ><br>
> > This type of edge case is my main concern, since with dirauths upgrading and<br>
> > going offline at random times, it's likely that we will eventually create a<br>
> > consensus without SR info in the middle of the protocol run.<br>
> ><br>
> > * Dirauth boots up at 23:55UTC without having a previous consensus. It is<br>
> > supposed to vote and form a 00:00UTC consensus without knowing any previous<br>
> > SRVs. How does it figure out whether all the other dirauths are also<br>
> > bootstrapping, or whether the other dirauths actually know the previous SRVs?<br>
> ><br>
> > Here are some prerequisites for the logic I'm going to suggest. The two first<br>
> > suggestions are useful in any case, I think:<br>
> ><br>
> > - First of all, we treat consensuses as trusted, so dirauths MUST learn<br>
> > previous/current SRVs they didn't know about from any consensus they fetch.<br>
><br>
> Yes ++.<br>
><br>
> A dirauth booting up should always try to learn the current and previous<br>
> SRV from the latest consensus (< 24h) and update the disk state<br>
> accordingly _even_ if the disk state has SRV values in there. We should<br>
> trust the consensus voted by majority before our disk state imo.<br>
><br>
> ><br>
> > - We are also going to assume that we have some sort of "SR flag" on votes to<br>
> > denote whether the dirauth participates in the protocol.<br>
><br>
> The requirements for having that flag "on" or "off" eludes me a bit. I<br>
> assume that this SR flag is "on" when a dirauth thinks its able to<br>
> compute a valid SRV that is I have enough commits. We can't make "having<br>
> the previous SRV" a requirement else we will never bootstrap properly<br>
> ever since in the first runs, previous SRV is alway 0.<br>
><br>
> ><br>
> > - We are introducing another 'status' for shared random values (see [SRVOTE]).<br>
> ><br>
> > Specifically, if a dirauth witnessed a 00:00UTC consensus failing to be<br>
> > created, or it did not contain any SRV information, then it sets the status of<br>
> > "shared-rand-current-value" in its votes to "none".<br>
><br>
> Hrm... I'm wondering here if "none" status is instead the same of having<br>
> the dirauth putting the disaster value in the vote?<br>
><br>
> I would argue that a dirauth should _always_ try to compute a SR value<br>
> at any time (even when booting). Between having no line because we<br>
> couldn't compute due to lack of commits or a line that is the disaster,<br>
> I think the former simplifies things that is "We always have a SRV value<br>
> at 00:00 from a dirauth".<br>
><br>
> Here is what I propose:<br>
><br>
> 1) Like you said, we always try to learn SRV values from previous<br>
> consensus. If we can't get one from a consensus or our state, compute<br>
> disaster at 00:00.<br>
><br>
> 2) We do _not_ use a SR flag for vote, a dirauth always tries to compute<br>
> a current SRV value at 00:00. If it's 13:00, it simply doesn't put<br>
> anything in the vote since no SRV data.<br>
><br>
> The big issue I see here is when a dirauth does _not_ have the previous<br>
> SRV. Without it, both disaster and current SRV computation will end up<br>
> not matching the majority. So let's explore this binary state:<br>
><br>
> - I have the previous SRV (either I can get it from my state or<br>
> consensus).<br>
><br>
> This seems a non issue, dirauth will use it, carry it in the vote and<br>
> compute the current SRV if enough commits have been seen. At 00:00, if<br>
> majority wasn't reached for the current SRV value, we have a consensus<br>
> without it which is a valid use case but we at least have the previous<br>
> one in the consensus flagged as non-fresh so it can be used for<br>
> disaster or SRV computation at the next protocol run.<br>
><br>
> - I don't have a previous SRV (couldn't get it in the latest consensus<br>
> and I have _no_ disk state).<br>
><br>
> For instance, if this happens at 23:30, a dirauth won't have the<br>
> chance to participate in the SR protocol because it didn't see any<br>
> commits to compute SRV value thus disaster mode engage.<br>
><br>
> If that dirauth was the 5th one out of 9 (meaning the majority<br>
> breaker), we end up with no SRV values at all at 00:00 (not even the<br>
> previous SRV since only 4/9 had it). So a new protocol run starts,<br>
> we'll end up with a valid current SRV in 24 hours and both values in<br>
> 48 hours. Essentially, we end up back in bootstrap mode.<br>
><br>
> IMPORTANT note here: I think a dirauth MUST NOT keep any SRV values<br>
> that aren't in the 00:00 consensus.<br>
><br>
> Question is, how big of a deal it is to have this issue where if we<br>
> don't reach majority because a dirauth rebooted and for some magical<br>
> reason didn't get the latest consensus to at least get the previous<br>
> SRV, we return in bootstrap?<br>
<br>
Ok more thoughts on this, asn asked that I make an algorithm so here is<br>
a try at that:<br>
<br>
-- Booting up Conditions --<br>
<br>
- A dirauth MUST try to acquire both previous and current SRV from<br>
the last consensus. If it can't, get it from disk state. If<br>
nothing is available, none exists for this protocol run.<br>
<br>
-- Algorithm --<br>
<br>
At 16:00 (arbitrary time which is _not_ the current SRV calculation):<br>
<br>
# Voting<br>
if dirauth has previous SRV:<br>
put it in vote<br>
if dirauth has current SRV:<br>
put it in vote<br>
<br>
Output: Consensus is created<br>
<br>
# Consensus<br>
(This goes for both previous and current SRV)<br>
if SRV in consensus:<br>
dirauth MUST keep it even if the one they have doesn't match.<br>
Majority has decided what should be used.<br>
else:<br>
dirauth MUST discard the SRV it has.<br>
<br>
At 00:00<br>
<br>
# Voting<br>
if current SRV can't be created because lack of commits:<br>
current SRV == disaster mode (previous SRV or not)<br>
else:<br>
compute current SRV (with or without a previous SRV)<br>
<br>
(Proceed like the 16:00 period)<br>
<br>
# Consensus<br>
if majority agrees on SR value(s):<br>
put in consensus<br>
else:<br>
No SR value(s) in consensus<br>
<br>
Output: consensus is created<br>
<br>
(Proceed like the 16:00 period)<br>
<br>
<br>
Side effect of only keeping SRV that are in the consensus. If one voting<br>
round goes bad for X reason and consensus end up with no SRV, we end up<br>
in bootstrapping mode that is no previous nor current SRV in the<br>
consensus which is problematic because for 48 hours, we won't have a<br>
previous SRV which is the one used by everyone.<br>
<br>
I don't see a way to get out of this because consensus is decided from<br>
the votes deterministically thus if not enough vote for SR values, we'll<br>
end up with a consensus with none so this is why client/HS have to<br>
fallback to a disaster value by themselves I think which can NOT be<br>
based on the previous SRV.<br>
<br>
David<br>
<br>
><br>
> Cheers!<br>
> David<br>
><br>
> ><br>
> > Now we are going to use the SRV lines in the votes as an indicator on how the<br>
> > consensus creation should play out.<br>
> ><br>
> > ================================================================================<br>
> ><br>
> > Here is some logic for the consensus at 00:00UTC:<br>
> ><br>
> > if majority of votes have disabled the SR flag:<br>
> > then don't write anything SR-related to consensus<br>
> > exit<br>
> ><br>
> > If the majority of votes contain the previous SRV value:<br>
> > then calculate SRV as detailed in section [SRCALC]<br>
> > else:<br>
> > then calculate SRV as in [SRCALC] but with previous_SRV set to 0<br>
> ><br>
> > And here is some logic for all the other consensuses (to figure out when<br>
> > dirauths should perform the disaster procedure):<br>
> ><br>
> > if majority of votes have disabled the SR flag:<br>
> > then don't write anything SR-related to consensus<br>
> > exit<br>
> ><br>
> > if we know the current SRV:<br>
> > then write it on the consensus<br>
> > exit<br>
> ><br>
> > if the majority of votes have the current SRV status as "none" _AND_<br>
> > those votes also contain the previous SRV value:<br>
> > then do the disaster SRV procedure<br>
> > else:<br>
> > then don't write anything SR-related to consensus<br>
> ><br>
> > ================================================================================<br>
> ><br>
> > This _might_ work for fixing a good bunch of edge cases. But is it far too complex?<br>
> ><br>
> > Should we just assume that these things will never happen on the real network<br>
> > and avoid baking additional complexity? What do you think? :/<br>
> ><br>
> ><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" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
<br>
<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" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 603 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/68e8133d/attachment.sig" rel="noreferrer" target="_blank">http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/68e8133d/attachment.sig</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<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" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of tor-dev Digest, Vol 58, Issue 39<br>
***************************************<br>
</blockquote></div><br></div></div>