I'll need to add a test for multiple overflows to see that I only increment on overflow.

@hugovk @eendebakpt Could you have a look at this? TL;DR: it shouldn't happen in practice because the counter is a randomized 41-bit integer and its max value is $2^{42}-1$ so we won't have an issue. The only possibility where this may be an issue is if the clock only goes backward for some reasons and we keep incrementing the counter for all the UUIDs being collected. Note that we can only hit the counter overflow after $2^{41}$ samples.

From a practical PoV, $2^{41}$ is honestly the limit of physical machines for attack complexities in general in terms of memory (for instance, decoding attacks are no more relevant if you need more than $2^{40}$ bits as it's more a physical limitation rather than a time limitation). So from a security PoV, it does make sense to fix this edge case.

So, for a realistic attack, (or issue) one needs one of the following situations to happen:

• clock only goes backward or we are never able to catch up the updated timestamps, and more than $2^{41}$ samples are collected to hit the first counter overflow; after the first counter overflow, the current code would update the timestamp more and more in the future, and we would never be able to catch it up.
• you need to generate $2^{41}$ UUIDs within the same millisecond. Highly improbable (we can generate $10^6$ UUIDs, but not $10^{12}$).

@picnixz I agree with your analysis. Whether or not to merge this PR (it fixes the bug) or leave as is (this will not happen in practice) I am 50/50 on.

I don't think we are loosing much speed. We are only adding one comparison every time we are within the same millisecond. But this adds a bit complexity that we will need to replicate in C though not necessarily hard to do. But still, it's a bit annoying I think. I can also document the implementation more.