Opened 14 months ago

Last modified 14 months ago

#31000 needs_information enhancement

Authorities should cap relay consensus weight as a new consensus method

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, tor-dirauth, tor-bwauth
Cc: arma Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor:


arma says on IRC:

armadev: teor4: is there a ticket for capping the total weight a given relay can get? i remember you mentioning that this should happen as a new consensus method, i.e. so the authorities actually collectively cap it, rather than relying on each vote individually to do it. i think that's a compelling idea.

I'm not sure if the cap should be the same across the network, or if it should be different based on each relay's MaxAdvertisedBandwidth.

If we want to base it on MaxAdvertisedBandwidth, we should also make MaxAdvertisedBandwidth a separate number in relay descriptor bandwidth lines, rather than combining it with bandwidth rate and bandwidth burst.

Child Tickets

Change History (4)

comment:1 Changed 14 months ago by teor

Status: newneeds_information

comment:2 Changed 14 months ago by teor

Summary: Authorities should cap relay consensus weight as a new consensusAuthorities should cap relay consensus weight as a new consensus method

Oops I did that thing where I

comment:3 Changed 14 months ago by arma

To be clear, the proposed idea is that when the directory authorities are creating the consensus, they should, as part of the algorithm to turn the votes into a consensus, make sure that no relay has more than x% of the consensus weight.

We earlier imagined having torflow (or later sbws) make sure that it would never give too high a weight to any single relay. But if each bwauth chooses its numbers independently, and then the dir auths just take the medium of each, that won't actually ensure that no relay will have more than x% of consensus weight. The only place to reliably guarantee it is in the consensus formation process.

comment:4 Changed 14 months ago by teor

We should disable this new feature on small networks.

(For example, if the limit is 5%, but the number of relays is less than 20, it is mathematically impossible to achieve the limit. And if the number is slightly more than 20, the weights are going to be very skewed.)

We should also think about whether we want a hard-coded limit, or we want the limit to be a consensus parameter. It would be annoying to have to add a consensus method every time we decide to change the limit.

Note: See TracTickets for help on using tickets.