There is no such thing as "entropy draining".<p>If it's higher-performance than other UUID generators, fine, that's a win. But it's not doing anything useful for the system as a whole by sparing the "entropy pool".
I wrote Yet Another UUID [1] for my own purposes recently as well. Mine's based on Firebase's style UIDs [2] -- they sort roughly chronologically, because operationally, I find that irritates me less. Arbitrary choice? Entirely. Regrets? None. Do I recommend it for use? Also not at all. Unless you feel like it. It's fine. I guess.<p>I've kind of given up on there being any purpose to a One True Spec for UUIDs. Count how many bits of entropy you want. Shove some CSPRNG into it. Call it a day.<p>¯\_(ツ)_/¯<p>(This a fine implementation, fwiw. I only mean to share my honest question as to whether there's any real utility to UUIDs-as-a-library.)<p>[1] <a href="https://github.com/polydawn/repeatr/blob/dd41ca72421a173b5aa14580f5d7df48df1548d0/lib/guid/guid.go" rel="nofollow">https://github.com/polydawn/repeatr/blob/dd41ca72421a173b5aa...</a>
[2] <a href="https://www.firebase.com/blog/2015-02-11-firebase-unique-identifiers.html" rel="nofollow">https://www.firebase.com/blog/2015-02-11-firebase-unique-ide...</a>
> NUID needs to be very fast to generate and be truly unique, all while being entropy pool friendly. NUID uses 12 bytes of crypto generated data (entropy draining), and 10 bytes of pseudo-random sequential data that increments with a pseudo-random increment.<p>> Total length of a NUID string is 22 bytes of base 36 ascii text, so 36^22 or 17324272922341479351919144385642496 possibilities.<p>Isn't 22 bytes = 176 bits?<p>UUID = 128 bit<p>Storage performance is more than per-ns on a CPU core, imo.
Why on earth would you care about entropy for a UUID?<p>You can use the most basic PRNG to generate your 128 bits. There's your UUID.<p>Call me when you find a collision.