Ask HN: We just had an actual UUID v4 collision... • Hacker News Board

Re: Ask HN: We just had an actual UUID v4 collision...

#301

Post by ssl-3 » Sat, May 09, 2026, 10:39 AM UTC

wpm wrote: post #274

BSVogler wrote: post #181

Earlier quoted context omitted.

I once read that noise of camera in total darkness is apparently a good source.

Would a CRT TV tuned to channel 3 and no RF input be a good source?

In the sense that RF noise can be a source of entropy: Sorta*. But one doesn't need the whole thrift-store television set to do that; the visual aspect of a CRT displaying analog video snow just adds style points**.

*: Sorta, because if someone discovers that the entropy is derived from an analog TV tuned to channel 3, then they also know how to influence it from outside.

**: Style points can have value; it's OK to have fun with work. But that's a secondary function.

Re: Ask HN: We just had an actual UUID v4 collision...

#302

Post by hun3 » Sat, May 09, 2026, 10:50 AM UTC

greiskul wrote: post #233

LocalH wrote: post #141

Earlier quoted context omitted.

This is why CloudFlare has done what they did with the lava lamp wall. Not that the wall is such a great source of entropy on its own - I'm sure it's not their only source, but you can never have too many sources of entropy - but it makes it visible in a way that can grab those who don't fully understand the concepts of RNGs and how entropy plays into that. The more sources of entropy, the more closely you approach "…

> you can never have too many sources of entropy This is so true. And the beauty is that with algorithms, we don't even need to know much about the entropy to be able to extract it. There is the Von Neumann method of generating an unbiased coin from a biased coin. Of throwing it twice, and checking if you got HT or TH. And completely discarding all HH or TT results. It doesn't matter if the coin you are using is 20%…

(Note that this still assumes that each biased-coin toss is i.i.d.)

Re: Ask HN: We just had an actual UUID v4 collision...

#303

Post by evnix » Sat, May 09, 2026, 10:52 AM UTC

All the probability mathematics aside, the real world we live in is probably a lot less random even with the best hardware random number generators.

I've moved on to something like TSID(where security isn't a factor) or uuidv7 to make sure this never really occurs in practice rather than over engineering the code with retries.

Re: Ask HN: We just had an actual UUID v4 collision...

#304

Post by [deleted] » Sat, May 09, 2026, 11:25 AM UTC

tliltocatl wrote: post #299

dheera wrote: post #221

Earlier quoted context omitted.

The lava lamps are just for show. You can get entropy just by plugging an oscilloscope into a pile of dirt and cranking the gain up.

Meh. The problem is that it might start receiving you local radio station and end up deterministic enough to screw you. So you need to shield the dirt properly.

[deleted]

Re: Ask HN: We just had an actual UUID v4 collision...

#305

Post by dgellow » Sat, May 09, 2026, 11:28 AM UTC

kdps wrote: post #210

dgellow wrote: post #48

Earlier quoted context omitted.

How confident are you that your machines clocks are in perfect sync? What about the risk of clock drift + correction, or hardware issues?

I get why sync of mutiple machines matters for ordering and causality, but why is it a problem for uniqueness?

I just read UUIDv7, something I wasn't familiar with until now. That does address everything I had in mind yes. I assumed timestamp-uuid meant purely based on the timestamp precision, in which case you can get conflicts if you don't have a reliable clock across your system.

But UUIDv7 looks pretty awesome:

> What is a Version 7 UUID made from?

> unix_ts_ms: 019e0c7bfe93

> ver: 7

> rand_a: 0b6

> var: b

> rand_b: 55a99e023294673

So please ignore my previous comment :)

Re: Ask HN: We just had an actual UUID v4 collision...

#306

Post by athrowaway3z » Sat, May 09, 2026, 11:39 AM UTC

The rule of thumb is simple:

Consider if your ID can contain a timestamp besides a random value. The answer is usually yes. UUIDv7 is fine.

If you've spend the time to really work through the whole problem and have written down a proof how that leads to unacceptable info leak: Congratulations your system is complex and slow enough that you might as well take a strong cryptographic hash or UUIDv5 if you're lazy.

Re: Ask HN: We just had an actual UUID v4 collision...

#307

Post by tremon » Sat, May 09, 2026, 12:02 PM UTC

lazide wrote: post #119

thecloud wrote: post #113

Earlier quoted context omitted.

Thanks for the insight! Mind expanding on what alternatives are being used in high reliability systems instead of UUIDv4?

Sequences, generally.

That depends on your definition of high-availability. If high availability includes distributed writers, (global) sequences are not the best solution because generating unique sequence values requires synchronisation between all writers. In those cases, you might need to explicitly partition the ID space so that individual writers are guaranteed not to get in each others' hair.

Re: Ask HN: We just had an actual UUID v4 collision...

#308

Post by beng-nl » Sat, May 09, 2026, 12:17 PM UTC

BobaFloutist wrote: post #101

Geee wrote: post #60

According to the many-worlds interpretation of quantum mechanics, there's bound to be one branch of universe where every UUID is the same. Can you imagine what those guys are thinking?

Not only that, there's vastly more where every UUID except one is the same, but they never got to that one because they didn't ever use them. Or where the first two are unique, but every following one is one of the first two.

One where all uuids are always different whenever the person who wrote the implementation tries it, regardless of computer. And whenever it’s someone else, always the same.

Re: Ask HN: We just had an actual UUID v4 collision...

#309

Post by dchest » Sat, May 09, 2026, 12:57 PM UTC

jandrewrogers wrote: post #149

thecloud wrote: post #113

Earlier quoted context omitted.

Thanks for the insight! Mind expanding on what alternatives are being used in high reliability systems instead of UUIDv4?

In high-reliability systems a criterion for identifier design is easy detection of defective identifiers. This includes buggy systems and adversarial manipulation. The problem with UUIDs that rely on entropy sources is that it is computationally expensive to detect if the statistical distribution of identifiers is diverging from what you would expect from a random oracle. I've written systems that can detect entropy…

How does a high-reliability system have a broken /dev/random? You're better off fixing it rather than trying to fix every downstream component that uses it. You can put your AES-128 counter there if you can count reliably.

Re: Ask HN: We just had an actual UUID v4 collision...

#310

Post by perlgeek » Sat, May 09, 2026, 1:15 PM UTC

D2OQZG8l5BI1S06 wrote: post #253

e12e wrote: post #121

Some discussion here: https://github.com/uuidjs/uuid/issues/546 Eg: > FWIW, I just tested crypto.getRandomValues() behavior on googlebot and it is also deterministic(!)

That makes sense. I'm not sure why anybody would generate UUIDs in browsers though, it seems to defeat the purpose.

When you do CQRS, you basically have to generate some form of unique identifier in the client. Why not a UUID in the browser?