The site doesn’t need people’s luck to find any active wallet, cause it could operate without them. The probability is so small that any reasonable time spent on including a spending routine would be pointless.
Unless the author trusts in luck or has too much free time on their hands.
Edit: or waits for someone to check a page containing their own private key.
Nah, it goes in an order. Base58check is used to convert byte arrays into the readable bitcoin addresses. So the the first address (5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf) has a byte array, in hex, of: 0000000000000000000000000000000000000000000000000000000000000001
Some people used those early addresses on purpose. Maybe for testing or something or I guess maybe due to a bug or something.
>> leads to the "end" page, it's not as I though a "big jump" from some random page... thus I suspect it's simply addresses that are low entropy, at the end of the range.
They're the trivial wallet addresses (close to the beginning and end of the search space). I would expect them to be used for debugging and testing in the early days.
> A private key is basically just a number between 1 and 2^256
It's like saying "I'm gonna pick a random number between 1 and a trillion", and then picking 999,999,999,995. Probably not a smart idea given that you don't want anyone else to be able to guess your number.
But the values are generally generated pseudo randomly by machine. This seems similar to the birthday problem, where the odds of encountering a value in a given range is higher than you'd expect.
1. yes, generally and ideally the private key is generated pseudo randomly. But at the beginning or for testing, people might have manually picked a private key.
2. the birthday problem basically halves the exponent security wise. The rule of thumb: If you have N possible outcomes, then after around sqrt(N) guesses the probability of a collision approaches 0.5. So, for birthdays, it's 365 outcomes, so with 19 or 20 people your risk of collision already approaches a half. For BTC private keys, there are 2^256 possible, so with 2^128 guesses you'd approach a likely collision. Fortunately, that's still 1e38, so if you check 1e10 per second, you'd still need 1e20 years to get there.
The birthday problem means that the number of values you have to choose to have a 50% chance of a collision scales approximately with the square root of the size of the space. [0]
2^(256/2) is way, way bigger than the number of used bitcoin addresses, which is about 33 million according to this csv [1].
ECDSA private keys can be arbitrary strings of random bytes of a certain length (unlike RSA, where we need to find prime factors). The first page is roughly the equivalent of using a low single digit number as your password.
It's a game like feeding the birds to see which bird will be able to grab the bread first.
Anybody can throw money and watch which robot will catch it.
Sometimes the addresses are reloaded (anybody can reload them by sending money to them). And usually when they are reloaded somebody grab the coins on the next block. The amount of money are not important ~1 USD.
Anybody that has guessed the private key can grab the money if he is aware that it has been reloaded, and then it has to pick the fees higher than the other so that his transaction get preferentially chosen by the miners.
The following address for example seems to be one of those bread crumbing bot : https://www.blockchain.com/btc/address/bc1q0ct0pus328qv2veln... (Note that the public address begins with (bc1q0ct0pus), (so presumably someone has searched for a private key whose public key has a fitting name for a bitcoin grabbing bot) that has managed to grab a few times recently from 1EHNa6... (the address whose private key is the first possible private key).
Presumably it has found other feeding spots as it has so far collected from different sources over the course of 1 year : 0.01274447BTC
I would expect this website, in the rare event of discovering some positive balance, to try spending it right away...