Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

261–270 of 369 posts

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

#261

Post by erikerikson »

keeganpoppen wrote: post #256
erikerikson wrote: post #246

Earlier quoted context omitted.

No I didn't miss it. DynamoDb works fine, using CQRS if necessary.

literally the whole point of randomly generating UUIDs is that you don't need to check for collision. that's what the "U"s are for. that is the abstraction that is supposedly being provided. "using " is not in any way a "scalable solution" for that with no other context. nor is just throwing out . the whole point is that it is a global (well, per name, "universal") abstraction that can, in practice, have holes that m…

I totally appreciate what you are complaining about. It's always been part of the documentation for a UUID. Having had Martin Fowler as a colleague and meeting with him weekly for a bit, I'd expect him to nod along with what I've written. It's standard knowledge and part of the technical corpus. As is actually distributed unique ID generation which is also not hard.

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

#262

Post by goalieca »

ai_slop_hater wrote: post #235
jubilanti wrote: post #198

Earlier quoted context omitted.

Yes, because UUIDv7 gives up some random bits in order to include the timestamp, which is done in a way that makes UUIDv7s quick to sort by timestamp.

How does including the timestamp expose me to adversarial exploitation?

I’ve not come across any.

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

#263

Post by erikerikson »

keeganpoppen wrote: post #257
orf wrote: post #244

Earlier quoted context omitted.

AKA centralising a decentralised identifier generator?

exactly lmao. that is exactly what is being presented as "scalable ". sigh .

No one has yet defined the scale but almost all of the real world scenarios people are actually encountering would be handled by either of the offered solutions.

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

#264

Post by tintor »

throwaway_19sz wrote: post #50

Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’…

Senior, Staff and Principal UUID Engineer.

UUID Database Admin.

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

#265

Post by pwython »

antonvs wrote: post #143
wolttam wrote: post #114

Earlier quoted context omitted.

The LLM is mechanistically unable to pick something actually random and outside of its training distribution, so... yep.

If you ask it to construct a UUID character by character you should get a somewhat random one, just because of temperature.

This actually worked well when I asked Gemini to generate a random color, character by character. I was getting Indigo/Electric Indigo a lot if I just asked for a random color on new sessions.

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

#267

Post by ranger_danger »

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

Reading the UUID spec leads me to believe that good entropy is not even a requirement for any version:

> Implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique").

From https://www.rfc-editor.org/rfc/rfc9562.html#unguessability

So I don't think technically we can say entropy or random numbers at all are even "required for UUIDv4 to work as advertised."

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

#268

Post by majorchord »

filcuk wrote: post #124
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?

The latest UUID (7?) Uses half random gen, half timestamp. This not only makes it sortable by creation, but would also make a collision like this impossible.

The spec doesn't require the use of actually random numbers though.

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

#269

Post by majorchord »

matt-p wrote: post #175
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?

UUIDv7 is arguably better, because it is entropy plus time.

Entropy is not a requirement in the UUID spec.

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

#270

Post by nyrikki »

victorbjorklund wrote: post #166
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 "…

If I understand it the Lava lamps are 90% PR/fun. They have a lot of other sources for entropy that scales better.

The original from SGI back in the mid 90's, before CPUs had RDRAND instructions etc... was a an actually practical solution.

At the time I was at the Internet company that originally got online-gaming banned in the US, we were looking at CCDs and Cesium emitters that required a license etc...

While I am not sure, it seems cloudflare basically implemented one after SGI's[0] patent expired.

The patent and the licensing cost and adding SGI was a major blocker for us doing it, the startup closed before we found a real solution. But the best PRNGs like Blum Blum Shub were way too slow at the time. But things did improve quickly at that time.

[0] https://patents.google.com/patent/US5732138A/en

Post reply on HN