I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?
they could spend each others coins.The keys don't need to be identical by the way - only their corresponding addresses.
Topic: probability that 2 clients generate the same public key? - page 2. (Read 4969 times)
The keys don't need to be identical by the way - only their corresponding addresses.
I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?
they could spend each others coins.
I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?
they could spend each others coins.
I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?
it would be 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 private keys
Similarly, what would be the size of a .txt file (in Megabytes) that had ALL possible Addresses & Privkeys in the following format:
11705361804156796183489345942421835167357080816800975597555641083563606016 MiB.Are you being sarcastic, or is this seriously a reasonable estimate of the file size?
Would like to see the math behind the result.
Not only do the reoccurring address-privkey strings take up a whole bunch of space, but you may be able to shorten down the private keys further by removing sipa's error correction. If you're generating standard-version addresses, you can strip the prefixing 1 out as well.
Or you can store everything in binary, without the base58 whatsoever. 32 bytes for a privkey, 20 bytes for an address.
Down to 5742252960529749071145716877414485176439322664845761613895220154201014272 MiB.
Similarly, what would be the size of a .txt file (in Megabytes) that had ALL possible Addresses & Privkeys in the following format:
For example, a .txt file with the below code is 212 bytes (0.000202178955078072 MB).
Not only do the reoccurring address-privkey strings take up a whole bunch of space, but you may be able to shorten down the private keys further by removing sipa's error correction. If you're generating standard-version addresses, you can strip the prefixing 1 out as well. For example, a .txt file with the below code is 212 bytes (0.000202178955078072 MB).
Code:
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyS
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tT
Similarly, what would be the size of a .txt file (in Megabytes) that had ALL possible Addresses & Privkeys in the following format:
11705361804156796183489345942421835167357080816800975597555641083563606016 MiB.
Similarly, what would be the size of a .txt file (in Megabytes) that had ALL possible Addresses & Privkeys in the following format:
For example, a .txt file with the below code is 212 bytes (0.000202178955078072 MB).
For example, a .txt file with the below code is 212 bytes (0.000202178955078072 MB).
Code:
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyS
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tT
Assume the entire bitcoin network's computational power is used for generating addresses, we'd see about 1000 billion addresses generated per second (it's around a factor 10 slower at least than hash testing). Assume this speed is maintained for as long as bitcoin mining is subsidized (until around 2140), we'd see about 4*10^17 addresses.
Since there are around 1.4*10^48 possible addresses, the chance that a duplicate is found can be calculated using the birthday problem as 1-exp(-(4*10^17)^2/(2*1.4*10^48)), or approximately 0.000000000005%, which means one in 20000 billion.
For all intents and purposes this chance can be considered 0.
Since there are around 1.4*10^48 possible addresses, the chance that a duplicate is found can be calculated using the birthday problem as 1-exp(-(4*10^17)^2/(2*1.4*10^48)), or approximately 0.000000000005%, which means one in 20000 billion.
For all intents and purposes this chance can be considered 0.
And if this is used as an attack, you aren't there yet with these methods. You would actually have to check every single public key that you just generated to see if there's actually money on it. So you actually have to compare each and every public key with over 1GB of data (The current size of the blockchain), slowing down this "attack" massively. A collision attack just isn't feasible, so no need to worry
Science
This all comes down to how good is Bitcoin random number generator. But even considering some weakness of keys, it will take away one or two zeroes from the number 0.000000000005% making it 0.0000000005%
Assume the entire bitcoin network's computational power is used for generating addresses, we'd see about 1000 billion addresses generated per second (it's around a factor 10 slower at least than hash testing). Assume this speed is maintained for as long as bitcoin mining is subsidized (until around 2140), we'd see about 4*10^17 addresses.
Since there are around 1.4*10^48 possible addresses, the chance that a duplicate is found can be calculated using the birthday problem as 1-exp(-(4*10^17)^2/(2*1.4*10^48)), or approximately 0.000000000005%, which means one in 20000 billion.
For all intents and purposes this chance can be considered 0.
Since there are around 1.4*10^48 possible addresses, the chance that a duplicate is found can be calculated using the birthday problem as 1-exp(-(4*10^17)^2/(2*1.4*10^48)), or approximately 0.000000000005%, which means one in 20000 billion.
For all intents and purposes this chance can be considered 0.
The BTC you would get by causing a collision would be a lot less than if you just mined lol
Yeah, the vast majority of the time that you find one of these incredibly unlikely collisions the address is empty anyway.
Hi, I seem to understand that public keys are generated randomly by the clients without any check that they already exist/are used, "just because" the chance that 2 or more clients generate the same key is "almost" zero. If correct, could this be a risk for anyone who wants to receive or transfer a serious amount of BTC? And, it would not be the case to implement a check when generating new keys?
A check is not possible. Your software doesn't know everyone else's private or public keys, only a subset of public ones. You can't even reliably restrict people from making duplicates of the known ones (in the chain) because Bitcoin is open source, people could just choose to keep the key by removing the check.
You have a much much greater chance of dying on the way to a bank and never getting your money than losing it to this insanely unlikely coincidence.
If you aren't very convinced of the astronomically small likelihood of a collision use vanitygen to try to make 10 chars of a key match and then try 15.
The BTC you would get by causing a collision would be a lot less than if you just mined lol
Your chances of hitting the megamillion lottery and being killed by a meteorite are far, far greater.
Your chances of hitting the megamillion lottery or being killed by a meteorite are far, far greater.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
There are 2 quindecillion possible PRIVATE keys that can be created from what I've been told. At normal rate it would take billions of years to generate them all. In order to generate them all, and considering they are 34 characters long, we would require more space than we have.
Jump to: