Bitcoin Forum

What mechanism for proof unique public key when creating a wallet happen with several sources(such as "wallet.btc.com" ,"wallet.bitcoin.com", "www.blockchain.com/wallet" and... )?

There is no way to prove that a private key or a public key you have generated is unique, and there is no central database of all generated/used private or public keys to compare against. The best you can do is use an open source piece of software such as Bitcoin Core or Electrum, where you can review the code and ensure that key pairs are being generated from random entropy. Provided your entropy is truly random, then the chances of generating the same key pair that someone else has generated are so low as to essentially be zero.

The three services you have listed are all web wallets which are closed source and generate your keys for you. In these cases, you are unable to verify they have been generated in a secure fashion, and therefore are indeed at risk of being given key pairs which are known to someone else.

Having the same public key also means having the same private key which means a 2^256 will give you an enormous number that a chance of finding a collision is so large than the total number of atoms that can be counted in the perceivable universe. Though generating the same public key is possible, but in reality, I don't think that's doable.

That's a ton of possibilities and there is no database that can actually store and verify that for you.

A good explanation has been given by o_e_l_e_o. Technically all private keys and public keys are unique. It's quite impossible to generate duplicate private keys on the Bitcoin blockchain. But the question is either your private key is compromised or not. When you are using a web wallet or any closed source wallet service means you have to trust them blindly since there is no way to verify if the private key has been compromised or not. So it's better to use an open-source wallet where you can read the codes if you have development skills.

There is no 'mechanism' behind it because no mechanism is needed, imho.
As previously stated, the process of creating a private/public key is so complex that the theoretical possibility of collision exists only as a mathematical probability and is practically equal to zero.

However, I agree with Coolcryptovator. A much greater risk is the credibility of the service and/or software you use to generate bitcoin addresses. If the software is open-source, you can be confident that hundreds or thousands of developers and programmers have already tested it, while with closed-source services, you have no idea what's going on under the hood.

That's not quite right. The process of creating a private/public key pair is not that complex and is actually pretty straightforward. The process of creating a private key is as simple as picking a random number between 1 and n-1. The reason the chance of collision if effectively zero is simply due to the sheer number of possibilities we are dealing with, as opposed to any complexity in the process.

This is not true. Open source software is a must, but just because it is open source does not guarantee safety. There are plenty of open source pieces of software, including wallets and Bitcoin Core itself, which have had critical vulnerabilities in them which have gone unnoticed for months or years.

I understand what you mean, but I believe that complexity can be expressed in a variety of ways. As it turns out, a collision resistant hash function that can map data of arbitrary size to data of fixed size is extremely difficult to achieve in mathematics. Therefore, I regard the mathematical function underlying the SHA-256 hash algorithm to be highly complex, despite being computationally incredibly fast.

Sure, but at no point in generating a private/public key pair do you need to use a SHA256 function (or any hash function, for that matter). If you want to take some random entropy, turn that in to a seed phrase, turn that in to a seed number, turn that in to a master private key, and then turn that in to individual private keys like hierarchical deterministic wallets do, then sure you use plenty of hashing, but that does not have any bearing on how unlikely a collision is.

I would accept the argument that elliptic curve multiplication could be considered a complex process, but again, that doesn't really factor in here. The reason we don't have public key collisions is because we don't have private key collisions. The reason we don't have private key collisions is as simple as because we have almost 2²⁵⁶ private keys to choose from, which is an unfathomably large number.

Oh, well, that explains it! I finally realized that I've been looking at this the wrong way. ;)

I concentrated on the fact that we cannot have public key collisions, that is, that two different private keys result in the same public key. Your argument is far more logical.