eta guesstimating
xeverse opened this issue · 8 comments
https://www.jamieweb.net/blog/onionv3-vanity-address/#generation-times
should be easily possible to guesstimate probabilistic chance & timing at runtime..
also see #27 (comment) and https://github.com/cathugger/mkp224o/blob/master/calcest.c
agree that it should be not too hard. idk if i gonna do that myself though.
It is easy enough to implement technically (except for with regex input), but doing the UX well will be much harder. From my prior experience with presenting similar information, there are many people who are really bad at understanding probabilities. If you say, "ETA 2 hours", there are people who will come back in two hours and freak out and think its "not working" because they didn't get a match yet. Even among people who do have an understanding that it's just an estimate, if you ask many of them after two hours without a match how much longer they would expect to wait before finding a match, most will answer with less than two hours.
My recommendation to anyone implementing this is to display a frequency over a large enough time span to find at least one match on average. For example, with a trial rate of 1 million calcs/second, the expected frequencies might look like this:
3-letter prefix: ~44 matches/second
4-letter prefix: ~1.4 matches/second
5-letter prefix: ~2.5 matches/minute
6-letter prefix: ~4.8 matches/hour
7-letter prefix: ~3.4 matches/month
...
This is a better design than displaying a time because it encourages people to wait for a longer the expectation, which will naturally result in an average interval between matches that more closely reflects the expectation. Additionally, there is some psychological difference in the scale: getting only 3 matches in a month when the estimate is 4 matches/month seems like less of an issue than going 15 days without a match when the estimate is 7.5 days.
On AMD Ryzen 9 5950X 16-Core Processor -> 7-letter prefix -> 60 generated in 6 hours -> 6 minutes on average per hit
@cathugger Is there any quick way to determine how many operations were performed in total given a checkpoint file? From a first glance, it looked like it should be a matter of converting the file bytes to integer, but it doesn't seem to be the case.
@dunsany The checkpoint file can be read as a 32 byte (not bit) unsigned integer in little-endian. The number of calculations should be roughly 2^21 times that number I believe.
@scribblemaniac At first, only a first couple of bytes were non-zero, so that was consistent with what you're saying. But now, my checkpoint file looks like this:
fcde 0efe fdfd fdfd fdff fdfd fdfd fdfd
fdfd fdfd fdfd fdfd fdfd fdfe fdfd fdfd
i think loading of checkpoint is actually missing a carry...