Earlier quoted context omitted.
But if it’s all Fs, that means you have the sign bit set, so it’s not the largest. It’s the smallest that’s less than zero right?
I guess it's pretty subjective, but not all numeric types are signed, so I'm happy with my answer.
Every V4 UUID
341–350 of 381 posts
Re: Every V4 UUID
#342Sometimes I feel bad when I generate a UUID without using it for anything. Like I've wasted it.
Millions of UUIDs generated! All so one would randomly be picked as the lowest valued and the attached record returned. Such a waste!
Re: Every V4 UUID
#343The fact that the search works impressed me more than anything. Of course, like every great magic trick, it seems so simple once it is explained. For the curious, here's the linked blog post describing how the project works: https://eieio.games/blog/writing-down-every-uuid/ Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even mo…
Re: Every V4 UUID
#344Earlier quoted context omitted.
"Must support 6-digit PINs" is not part of "the spec for secure credit card transaction handling" – which is also not a (or at least one) thing: There are dozens of card networks, and many of them have tons of regional variations. In some markets, issuers only allow 4 digit PINs, and customers don't expect to have to press an "enter" key when they're done entering their 4 digit PIN – so the reasonable implementation…
4 is the minimum number of digits required, but there are over a dozen different PIN block standards, and most allow between 4..9 and 4..16 digits: https://www.eftlab.com/knowledge-base/complete-list-of-pin-b... Making an ATM that can accept cards from multiple issuers (which is the norm these days) and allowing only 4 digits is the same category of error as requiring that the first character of someone's last name s…
> there are over a dozen different PIN block standards
You almost certainly don't need to support all of these inside the PIN pad or even ATM/POS. If necessary, translation can happen in other parts of the system.
Re: Every V4 UUID
#345I found the Pi UUID: 185e45bc-750b-43d7-91ee-314159265358
Re: Every V4 UUID
#346Earlier quoted context omitted.
> or to block symbol characters in names. People tend to very very quickly their mind on that one once they get a few right-to-left control characters that flip over the text layout of the entire program.
"We'll just not do business with anyone named O'Neill, that's just a made-up name designed to trick the database with SQL injection." Also: https://www.ancestry.com.au/name-origin?surname=null
The reality is that there is often a tradeoff between keeping your test and edge cases simple via constraining allowable inputs and internationalization.
So I think you've got it exactly the wrong way around: These limitations might have happened precisely because somebody wanted to do the right thing from a safety/security perspective by doing overly strict input validation, at the expense of internationalization/compatibility.
Not saying that that's a good tradeoff in every case, but I really don't think you can draw any conclusions about a system's security by looking at whether it arbitrarily disallows some inputs (or if anything, maybe the opposite).
Re: Every V4 UUID
#347Very useful! I'll refer to it when I forget my UUIDs, I use this site all the time to remember my bitcoin private key [0] [0]: https://privatekeys.pw/keys/bitcoin/1
Thanks for this, I didn't know that people create weak BTC keys for fun. I guess some are also used as bot honeypots?
Re: Every V4 UUID
#348Earlier quoted context omitted.
I considered this, but I'd just be so unsatisfied if I finished scrolling through all 2^128 rows and realized I'd seen some duplicates!
I liked the approach movpasd suggested: https://news.ycombinator.com/item?id=42346076 With a linear algebra library, you can guarantee that you've found the next, or the previous, match in sequence. I don't know what the state of the art is for fast linear algebra in javascript, though. (The matrix approach also has the advantage that, when your full-text search problem has 2^115 solutions, you can compute the one yo…
very fun to have received so many pointers here, hopefully I'll be able to do a follow up blog once I've finally let people find all the good UUIDs
Re: Every V4 UUID
#349Earlier quoted context omitted.
FWIW I am super interested in this question but feel like I don't know how to derive a satisfying answer, maybe because the one of my goals here (add "enough" entropy) is a real fuzzy "I know it when I see it" sort of thing. But I'm gonna try to get a few more crypto-knowledgeable friends to chat with me about this and write up what I learn!
My first thought was to use linear transformations over Z_2 as a field, as that would create a natural interpretation of fixing certain bits as taking a linear subspace. Interestingly this leads to the property that XOR is preserved. I implemented this in a very quick and hacky way for 32 bits. I generated a random boolean matrix M invertible in Z_2. To turn an input number x into a corresponding number y in an N-bit…
Re: Every V4 UUID
#350The fact that the search works impressed me more than anything. Of course, like every great magic trick, it seems so simple once it is explained. For the curious, here's the linked blog post describing how the project works: https://eieio.games/blog/writing-down-every-uuid/ Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even mo…
I'm really happy that the trick was magical to you - I was so surprised and delighted when I realized that this was possible, and I wasn't really sure if anyone else would feel the same way! And of course, I'm proud to be providing so much utility here - finally we can find and use UUIDs tailor-fit to our needs
I wonder if there's (yet) a browser API you could hook into: the same way browsers allow JavaScript to manipulate the history [1], maybe there's a way to manipulate the Ctrl+F/find-in-page search results.
[1] - https://developer.mozilla.org/en-US/docs/Web/API/History_API
That is, right now you're capturing the Ctrl+F keypress and opening your own custom thing to read the user's search string and act on it. But what we'd really like is a way to be notified "The user just asked to search for 'xyz'. Would you like to capture that event, or let it go through to the browser's default behavior?"
A quick Google search found nothing like that exists yet. I then asked ChatGPT about it, hoping that ChatGPT would at least hallucinate a plausible design for the API — and had mixed feelings when it didn't. It just printed that 'Browsers do not provide a way to listen for the "Find in Page" search event due to privacy and security concerns' and suggested capturing the Ctrl+F keypresses exactly as you have done.
As someone else said, it would also be more like full-text search if you also considered the primary-key column, e.g. searching for "0390814603917539994005679487460590835" should jump to the 390814603917539994005679487460590835th row. (Highlighting-to-select pieces of the text also doesn't work: I'm not sure why not, since I would have thought the browser gives you at least that part for free.)
Besides "search" not working on mobile, the styling on mobile is such that the "scrolling" does not convince: to my eyes it looks too obviously like "changing the values in the cells of a fixed table" as opposed to "scrolling through the table itself." You could maybe mitigate that by animating quickly among three different page layouts with the table vertically offset by different amounts.
It occurs to me that if JavaScript has something like Python's `random.sample`-without-replacement, then you could set your `RANDOM_SEARCH_ITERATIONS` to 256 and achieve perfectly consistent (and exhaustive) "search" when the user has entered all but 1 or 2 hex digits of their desired result. And/or, you could just have the page secretly keep a history of the search results the user has already seen: this would prevent the user from finding out so quickly that "search + next + next + prev + prev" doesn't always get them back to where they started.
Speaking of exhaustive search results: With a bit more (probably equally algorithmically interesting) work, you could emulate the browser search's "7/256" by tallying up the number of UUIDs satisfying the constraint, e.g. if the user has typed "1234567" then you could display "1234567 (158456324585806817418058661888 results)" and maybe even fake up a convincing position indicator like "1234567 (17415833585801881134805987465/158456324585806817418058661888)". I guess if you display it as "1234567 (1.742e28/1.585e29)" then you don't even have to cheat that much. :)