If I assigner the numbers, I would carefully print 8 billion or so slips with different numbers, and place them in an urn. For each person, I'd draw from the urn, and then the probability of me assigning the same number to two humans is related to IT failures during generation. How many dollar bills share a serial number unintentionally?
https://shinesolutions.com/2018/01/08/falsehoods-programmers...
to what degree do you think birth times are actually rounded rather than accurately recorded?
very much not done :)
The quoted sentence is found immediately below the heading "19 random digits is not enough to uniquely identify all human beings" in the linked article. So... actually, it is specifically talking about random numbers.
And then the response...
> If I assigner the numbers, I would carefully print 8 billion or so slips with different numbers, and place them in an urn. For each person, I'd draw from the urn, and then the probability of me assigning the same number to two humans is related to IT failures during generation. How many dollar bills share a serial number unintentionally?
Is pretty blatantly describing a randomization procedure, if not going quite so over-explaining far to say "I draw from an urn without replacement and with some level of randomization to my movements and without knowledge or any tactile or other hints of which slip of paper is which"...
1. Give the first person who asks the number 0000000000000000001.
2. Give the next person the previous person's number plus one.
3. Repeat.
The drawing-from-an-urn randomization or hashing is unnecessary if you just start with 8 billion or more numbers.
This is literally the technique I use at work for keeping track of part numbers: There's a single server that my individual CAD users can ask for a part number to describe the components of their assemblies, it does nothing but generate sequential, unique numbers. Engineers can't draw millions of parts per second, so it just works...and there's no probabilistic element with associated birthday paradox to the uniqueness of those IDs.
There are only 4.5 people born per second for this hypothetical server to handle in the long term. And at INSERT speeds of something like 3M/second, you could theoretically handle the initial storm of requests to serve all current living humans in about an hour. With 2^64 records, this scheme should be good for about 100 billion years assuming population growth levels off. That's a long time for that assumption to hold true, but I think optimizing for an event that might be only 50 billion years away is a little premature (also, the timeout when querying this server from Alpha Centauri might limit your transaction rate, but again, premature optimization).
* Better support for people born in an area without an internet connection (or with a spotty internet connection).
* No need to agree on a single issuing authority.
People are clever though and just began using the length of their string as their personal ID.
Edit: Also, would you mind changing that statement to not leave a preposition shooting off the end like Wile E Coyote?
This is the kind of pedantry up with which I will not put.
For once it'd be nice if we punted the problem a lot further than 100 years down the road.