Consider disabling dynamic intro point formula (numerology)

This ticket was repurposed and it's now about discussing the dynamic formula for determining the number of introduction points of a hidden service.

The formula leaks the popularity of the hidden service on an hourly basis. Furthermore, it's memoryless which causes the hidden service to use a much bigger number of introduction points than normal (comment:15:ticket:15513).


In #3825 (moved) rransom proposed to tune the number of IP to rebuilt once one expires based on the history of the Tor HS usage. I believe these numbers are not optimal and there should be a better way to do this.

These are the first numbers that I will try to estimate: I = number of intro points C = Connections made to an IP in it's lifetime T = Total number of connections made to the HS in 24 hours

What we are interested in estimating is the value of NUM_INTRO_POINTS_MAX and this is based on the estimation of C. To determine this we will consider this equation:

I = T/C

I believe it is reasonable to suppose that a very busy HS will at most have 1M connections in 24 hours. This means that:

I = 1'000'000/C

Currently C is set to 16384. I am not sure why this number was chosen, but if this number is good we would need to set the value of I to 61.

Lets take for granted that 61 is a good value for NUM_INTRO_POINTS_MAX, this means that the number of active IP at a given time should be in the range of 3-61.

For this reason I believe it would be good to have the number of IP to recreate to be in the range of 1-20 dependent on the history of a Tor HS.

The basic thing we can do is use a linear function to determine this number x. We want a linear function that has these properties:

f(0) = 1``f(4/3) = NUM_INTRO_POINTS_MAX ``(supposing that for lifetime of IP tends to end the fraction (time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT) -> 4/3) This leads us to this:

x = (1 - NUM_INTRO_POINTS_MAX)*((time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT)) + 1

in the case of NUM_INTRO_POINTS_MAX = 20 this means:

x = 25.3333333 * (time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT) + 1

A better way to do this is have an exponential function that converges asymptotically to 20.

Does this seem sane?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information