Skip to content

Estimates should be based on sparser sampling #4

Open
@gibson042

Description

@gibson042

The estimated time of a mainnet block that's three to four days out is highly dependent upon sample count, which suggests that block duration is variable by (among other factors) time of day. So rather than querying the N most recent blocks, it would make sense to spread the samples out.

Suggestions:

  1. When estimating the time of a future block, sample durations randomly within a range that goes back a number of blocks equal to the difference between the current height and the height to be estimated (e.g., if the current height is 10000 and the target height is 15000, then times should be sampled from starting heights 5000 to 9999). If the range is not big enough to satisfy the sample count, then expand it backwards to perform complete sampling as in the current implementation.
  2. When estimating the block height of a future datetime, calculate how far in the future it is and then find a block height that is that far in the past (by e.g. extrapolating backwards from the most recent block duration and then using linear estimation) to use as the start of the range (as above, expanding backwards if it is not big enough to cover the requested sample count).
  3. When using statmode "mean", sample only the endpoints.

This tool is intended for near-term estimation, so I think it's fine to fail if a requested block is so far in the past that it has been pruned. But alternatively, that situation could be detected and used to dynamically update the lower bound for block height sampling.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions