Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You are talking about a v1 UUID.

A random number is a valid v4 UUID, provided you set the version and variant bits to the correct value. A random 128-bit number won’t have those bits correctly set (except by chance). Set them, and you’ve made a valid v4 UUID



As you say, you need to set certain bits to special values to encode a v4 UUID, leaving less than 128 bits for the payload, which means a random 128 bit number is not a valid UUID except by chance.

Second, a v4 UUID should set all remaining bits randomly. Encoding a timestamp in some of the bits is not random. Sure, you could argue these could have been randomly generated by chance, so any such UUID is not invalid, strictly speaking. Still, a collection of these v4 UUIDs don't have the properties that you would expect of random UUIDs.

As specificed, the scheme satisfies neither of these two requirements.


There’s always the expired v6 proposal: https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-...


bit perplexed why this never went anywhere. Seems like a solid win all around really given where uuids show up.


Exactly. And the v4 UUID will have 122 bits of randomness.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: