> 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.
