Opened 3 years ago

Last modified 21 months ago

#19045 needs_revision enhancement

Keep trying to form a new shared random value during the next commit phase

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-sr tor-dirauth robustness
Cc: Actual Points:
Parent ID: Points: 0.2
Reviewer: Sponsor:


Currently, the shared random system treats the first vote of the next commit phase specially - it's the only time it tries to agree on a new shared random value.

But we can try to agree 12 times on a new shared random value like this:

  • for the first consensus in the new commit period:
    • vote the calculated shared random value;
  • for subsequent consensuses in the new commit period:
    • if we have an agreed shared random value from a trusted, previous consensus in the period, vote that value;
    • if not, (if the new shared random value is missing from the consensus, or there is no trusted consensus), continue to vote our calculated value.

This way, we try up to 12 times to agree on a shared random value. (But we never change an agreed value after we've agreed on it.)

Child Tickets

Change History (14)

comment:1 Changed 3 years ago by nickm

Keywords: 029-nickm-unsure added

comment:2 Changed 3 years ago by teor

Keywords: 029-teor-yes added
Points: small

I think this is a very small change:

  • keep the shared random value calculated from the state file
  • replace it with the consensus shared random value, when a consensus forms
  • expire non-consensus shared random values at the end of the commit phas

comment:3 Changed 3 years ago by teor

Status: newneeds_review

Please see my branch srv-try-again on

If the majority voted for a current SRV, we put that in our state. If there is no majority SRV, we keep our idea of the SRV for future votes. If we reach the reveal phase without agreeing on a SRV, we give up and stop voting for our idea of what the SRV could have been.

We might decide to stop retrying votes for an SRV part-way through the commit phase.
For example, if clients take up to 3 hours to get a consensus, we should stop retrying 3 hours before the start of the overlap period.

We'll need to be careful to do the right thing on sr_act_post_consensus(NULL), but it can't happen at the moment.

comment:4 Changed 3 years ago by teor

Keywords: tor-hs added

comment:5 Changed 3 years ago by nickm

Keywords: 029-proposed removed
Milestone: Tor: 0.2.???Tor: 0.2.9.x-final

Adding these to 0.2.9 since they (appear to be?) dependencies of stuff that's already in the milestone.

comment:6 Changed 3 years ago by arma

I haven't reviewed the code, but the description in this ticket matches what I think teor and asn and dgoulet and I discussed right before I ran out of the Montreal meeting. So, yay.

comment:7 Changed 3 years ago by dgoulet

Points: small0.2
Reviewer: dgoulet
Sponsor: SponsorR-must
Status: needs_reviewneeds_revision

The current proposed patch won't work with the new latest code.

Let's wait until #16943 is merged before trying anything else. It was a decision we took at the Montreal hackfest with armadev, teor, asn and dgoulet.

comment:8 Changed 3 years ago by dgoulet

Keywords: prop250 added; 029-nickm-unsure 029-teor-yes removed
Milestone: Tor: 0.2.9.x-finalTor: 0.2.???
Parent ID: #16943
Sponsor: SponsorR-mustSponsorR-can

Removing parent ID here else we won't be able to close #16943 once it's merged. Also, removing it from 029 because our 029 milestone has too many things and this can possibly wait. I did a cleanup of the keywords as well. It's now tagged prop250 and tor-hs so this won't be lost in the darkness of trac.

comment:9 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:10 Changed 2 years ago by dgoulet

Keywords: tor-sr added; prop250 removed

comment:11 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:12 Changed 22 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:13 Changed 22 months ago by dgoulet

Keywords: tor-hs removed
Reviewer: dgoulet
Sponsor: SponsorR-can

comment:14 Changed 21 months ago by nickm

Keywords: tor-dirauth robustness added
Note: See TracTickets for help on using tickets.