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