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 legacy/trac#3825 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?