probability that 2 clients generate the same public key?

[conspirosphere.tk]

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?

[1713877831]

1713877831

[1713877831]

1713877831

[1713877831]

1713877831

[1713877831]

1713877831

[Remember remember the 5th of November]

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.

[stevegee58]

Your chances of hitting the megamillion lottery or being killed by a meteorite are far, far greater.

[FreeMoney]

Your chances of hitting the megamillion lottery and being killed by a meteorite are far, far greater.

[drakahn]

The BTC you would get by causing a collision would be a lot less than if you just mined lol

[FreeMoney]

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.

[FreeMoney]

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.

[Pieter Wuille]

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.

[MysteryMiner]

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%

[science]

Science

[Mushoz]

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.

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

[ForceField]

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

Code:

Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyS
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tT

[Pieter Wuille]

Similarly, what would be the size of a .txt file (in Megabytes) that had ALL possible Addresses & Privkeys in the following format:

11705361804156796183489345942421835167357080816800975597555641083563606016 MiB.

[mcorlett]

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

Code:

Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyS
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tT

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.

[Pieter Wuille]

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.

[ForceField]

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.

[drakahn]

it would be 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 private keys

[Mr.Coin]

I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?

[vuce]

I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?

they could spend each others coins.

[MysteryMiner]

I know the chances of 2 exact keys is mindbogglingly small, but what would happen if there were?

they could spend each others coins.

It will look exactly like Allinvains case.