same private key?

[witcher_sense]

Until now I have never encountered an event that has the same private key between one and another, in other words almost
impossible to happen. Let's just say that someone who has the same private key as I have, means that i can access his wallet
and vice versa. After all, if there is anyone who has the same private key, it is impossible for each other to know. Because
everyone keep a private key in a safe place, which is impossible for others to know.

If anyone found precisely the same private key as yours, he would never deposit any bitcoins on the corresponding public address, thus he would never tend to keep it safe. The first thing he would do is withdraw existing balance to another address, over which he would have full control. So, if you still scared of someone finding your private key, use hierarchical deterministic wallets (HD-wallets) in which you will only have to keep a seed phrase that is used to derive private key/public key/address for each payment.

[1714056683]

1714056683

[1714056683]

1714056683

[1714056683]

1714056683

[vapourminer]

I suppose when you think about it, the chances of someone randomly guessing your email and bank password are much higher than getting access to your BTC.  Email 30 characters max and passwords 6 to 16. That is a lot less combinations to try.

except the bank will lock your online access after a set number of failed logins, typically three.

the only limit to how many guesses you can try for bitcoin private key is your computational power.

[ranochigo]

If anyone found precisely the same private key as yours, he would never deposit any bitcoins on the corresponding public address, thus he would never tend to keep it safe. The first thing he would do is withdraw existing balance to another address, over which he would have full control. So, if you still scared of someone finding your private key, use hierarchical deterministic wallets (HD-wallets) in which you will only have to keep a seed phrase that is used to derive private key/public key/address for each payment.

HD wallets are not any significantly more secure as compared to the non HD wallet.

While it is true that a HD wallet allows you to have a higher entropy as compared to just bruteforcing addresses, the Bitcoin public key that is generated (ECDSA) already gives 128bits of entropy. That, by itself is sufficient enough. BIP32 allows you to go above and beyond that level but it is just redundant. It would be exponentially harder to bruteforce seeds with higher security but it doesn't offer a significant advantage over any keys that has >128bits of entropy.

[witcher_sense]

HD wallets are not any significantly more secure as compared to the non HD wallet.

While it is true that a HD wallet allows you to have a higher entropy as compared to just bruteforcing addresses, the Bitcoin public key that is generated (ECDSA) already gives 128bits of entropy. That, by itself is sufficient enough. BIP32 allows you to go above and beyond that level but it is just redundant. It would be exponentially harder to bruteforce seeds with higher security but it doesn't offer a significant advantage over any keys that has >128bits of entropy.

To clarify, I am still considering private key nearly impossible to bruteforce even if public key is known. Essentially, HD-wallets is simply more convenient way to "spread" coins across several addresses and also users don't have to back up each key. If someone finds one of your private keys (still impossible, but), he won't be able to steal an entire balance of HD-wallet.

[pooya87]

I suppose when you think about it, the chances of someone randomly guessing your email and bank password are much higher than getting access to your BTC.  Email 30 characters max and passwords 6 to 16. That is a lot less combinations to try.

except the bank will lock your online access after a set number of failed logins, typically three.

the only limit to how many guesses you can try for bitcoin private key is your computational power.

yeah but also there are other ways of getting into your bank account that may not even involve using a login. after all your bank account is just an entry in a centralized database that can easily be hacked.
your bitcoin key still remains the same impossible to break key.

[o_e_l_e_o]

except the bank will lock your online access after a set number of failed logins, typically three.

the only limit to how many guesses you can try for bitcoin private key is your computational power.

True, but let's put some math to that for any newbies reading this who might be worried.

Let's say my online bank password is truly random and drawn from the full 95 character ASCII set. Something along the lines of c"AQ+K78[={2W+9t, for example. (In reality, this is significantly more secure than the VAST majority of passwords which are being used, but we will error on the side of caution.) If someone has 3 attempts, then the probability of them guessing my password is 3 out of 95¹⁶, which is a probability of 6.8*10^-32. Given that there are 2²⁵⁶ private keys, for someone to have the same probability of finding my private key, they would have to check 7.9*10⁴⁵ private keys. Even checking a trillion trillion keys every second, it would still take 250 trillion years for them to do so. I'm happy to take those chances.

Also worth pointing out that the chance of someone guessing your credit card PIN or even your long credit card number is astronomically more likely than either of the above scenarios.

If someone finds one of your private keys (still impossible, but), he won't be able to steal an entire balance of HD-wallet.

It's always worth noting the caveat to this - if you have revealed your extended public key (as you might do when setting up a watch only wallet), then the additional knowledge of the private key of one single address in that wallet would allow an attacker to calculate all the private keys in that wallet.

[vapourminer]

It's always worth noting the caveat to this - if you have revealed your extended public key (as you might do when setting up a watch only wallet), then the additional knowledge of the private key of one single address in that wallet would allow an attacker to calculate all the private keys in that wallet.

yup. good reminer. didnt know that way back when i set some some watch only wallets.. soon as i realized that i moved everything off to a new wallet.

[Shasha80]

This is a very good topic in my opinion, it would never thought to me if there really is a person who has the same private key as me.
This is a scary thing, that person can have full control over my wallets. Hopefully nothing happens to me. Occasionally someone's wallets
are hacked even though they already use maximum security, possibly that hacker having the same private key.

[erikoy]

Even slight chances having the same private key still it will give doubt to the users. Who knows that out of luck your holdings will be shared to the same wallet private key. This is somehow what we call a really2x bad luck out of the so many private keys you two had made the same. LOL, anyway as it was mention from other usera that it is bwing close to impossible. Well just hope that the system will not going to make any duplications regarding with private keys so as to protect holdings and should not be to become the most unfortunate btc user.

[webtricks]

hey,
I wonder, even if the probability so small is, if someone else get the same private key as me could he/she spend my Bitcoins and viceversa? would we have the same Bitcoin Adress?

you may not necesarily have the same bitcoin account as it changes upon every transaction depending on the wallet you are having its keys (not exchanger wallet). but be rest assured that it is one private key to one wallet. whether or not the private key is in the hands of two people but also note that the algorithmn can not generate two identical private keys on its blockchain as it was not design to perform in that capacity.

Which algorithm are you talking about? Addresses are not generated on blockchain. There is no algorithm that checks if a private key is already into use. There is no record of any private key on blockchain.

Also, one private key doesn't mean one wallet. One private key means one bitcoin address. The example you gave in which Bitcoin Address changes after each transaction is HD wallet which is generated using seed which is derived from mnemonic code and passphrase. I don't know why I am explaining at all, your bitcoin knowledge is horrendously wrong.

[Velkro]

It's more possible to win 10 jack pots on a row than finding the same private key with someone else.

Big numbers don't make people understand. Sentences like this do. Its easier to imagine things with it.
Its possible but so unlikely that impossible in reality.
You can also easy secure yourself, second address you own is risk with this slashed by half.

[3L3]

I have a similar question to OP: can (not asking if likely or not, just asking if possible) collision occure in BIP39 Mnemonic?

For example, can a 12-word mnemonic produce the same wallet/pk/etc than, lets say, a 36-word mnemonic phrase?

[BlackHatCoiner]

The whole security system for bitcoin is not that it is impossible (which would be good) but that it is vvvveeerrryyy unlikely.

It is impossible to have a security system which is impossible to hack, and as far as security systems go, bitcoin's is pretty darn good.

Given that most 2FA codes are 6 digits long, there is a 1 in 10⁶ chance of someone guessing your 2FA code.
Assuming an average house lock as 8 tumblers, and each tumbler can adopt one of 10 positions, then there is a 1 in 10⁸ chance that someone will be able to guess your exact house key shape and unlock your door.
Given a standard credit card has a 15 or 16 digit number on it, there is at most a 1 in 10¹⁶ chance that someone will be able to guess your credit card number.
If you use a password manager to generate a long and totally random 16 character password, drawing from the full ASCII 95 character set of upper and lowercase letters, numbers, and symbols, (e.g. CY\u4"=t{rV%;N9S), there is a 1 in 4.4*10³¹ chance of someone guessing it.
The chance of someone guessing your private key is 1 in 1.158*10⁷⁷.

The chance of someone correctly guessing your password, your 2FA code, your credit card number, and the key to your house simultaneously is 4.4*10⁶¹, which is still around 2 thousand trillion times more likely than them guessing your private key.

The difference is that you can't guess 1 billion different credit cards in a second. There are blockers. They won't let you. In the private key, on the other hand, do your best!

Of course, I don't say, guessing the privkey is much harder that all of the things you've said, but you don't have the same opportunities.

[htsy585]

hey,
I wonder, even if the probability so small is, if someone else get the same private key as me could he/she spend my Bitcoins and viceversa? would we have the same Bitcoin Adress?  

It's not possible for anyone to get your private because it is some sort of random generated alphabets which only you have authorized access to unless you gave it out or your wallet got compromised through hack and security breach or by submitting your private keys to fake and phishing sites.

[o_e_l_e_o]

For example, can a 12-word mnemonic produce the same wallet/pk/etc than, lets say, a 36-word mnemonic phrase?

Seed phrases are generally 12 or 24 words long, sometimes 15, 18, or 21, but pretty much never 36.

Given that each seed phrase can derive trillions upon trillions of addresses, then the same address will show up under two different seed phrases at different derivation paths. It is also possible that two different seed phrases (potentially with different specific passphrases), would generate the same 512 bit seed number and therefore identical wallets, but the chances of a collision in a 512 bit space is astronomically smaller than the already astronomically small chance of a collision in a 256 bit space.

So yes, it can theoretically happen, but no, it will never actually happen.

[Mpamaegbu]

is it possible to get someone else's address or will it be skipped?

Theoretically it is possible, but in reality it will never happen. There is certainly no mechanism or database that wallets or exchanges use to check if an address has already been used when generating new private keys.

The reason it will never happen is simply down to math. The numbers we are dealing with here are unimaginably large. For example, if every human on the planet each generated 1 million new addresses every second, and had been doing so since the birth if the universe 13.7 billion years ago, we would only have generated approximately 0.0000000000002% of all possible addresses.

This is really some deep stuff. I used to get bothered the same way noorman0 was and would always crosscheck to see if my transactions actually landed in my account on exchanges. Even on this forum when new entrants are asked to pay a fine for "IP cleansing", I used to wonder how that particular generated address is specific to that account. Now I know. Thanks buddy for your explanation.

[witcher_sense]

It's always worth noting the caveat to this - if you have revealed your extended public key (as you might do when setting up a watch only wallet), then the additional knowledge of the private key of one single address in that wallet would allow an attacker to calculate all the private keys in that wallet.

It is very interesting area I still hardly understand. Let me summarize. In order to derive master private key (m), we use root seed phrase as an input in HMAC-SHA512 function. But. Since the output of the function is 512 bits number, it is worth to note that left part of that number is our master private key and right part is our master chain code (c). Master chain code is further used as entropy in the HMAC-SHA512 function to calculate child key. Extended private key is a 512 bit number, in other words this is a direct result of initial calculation - private key + chain code. Extended public key is a master public key + master chain code. If I get it right, since extended public key contains master chain code, this code plus leaked child private key can be used to calculate both child private keys and parent private key. And what about hardened derivation when parent private key is used to calculate child chain code? Then it supposed to be safe to use xpub derived from hardened parent key...

[o_e_l_e_o]

In order to derive master private key (m), we use root seed phrase as an input in HMAC-SHA512 function.

Not quite. "Root seed phrase" isn't really a term that is used. "Root seed" is a 512 bit number, while "seed phrase" is your 12 or 24 words.

Your seed phrase (plus optional passphrase) are the input parameters for 2048 rounds of HMAC-SHA512 to produce your 512 bit "root seed" number. Your root seed then undergoes a further HMAC-SHA512, where the left 256 bits become your master private key and the right 256 bits become your master chain code.

Master chain code is further used as entropy in the HMAC-SHA512 function to calculate child key. Extended private key is a 512 bit number, in other words this is a direct result of initial calculation - private key + chain code. Extended public key is a master public key + master chain code.

This is generally correct, but be careful mixing up the terms "master" and "extended". Master keys and master chain codes refer specifically to the top level of the derivation path - the "m" in m/44'/0'/0'/0/0, for example. Extended keys refer to the key (public or private) concatenated with the chain code for that specific level, and can occur at any level in the derivation path. For example, the extended keys for a standard wallet are at derivation path m/44'/0'/0'. These let you generate addresses for that particular account, but don't let you swap to other accounts as you could do with master keys.

If I get it right, since extended public key contains master chain code, this code plus leaked child private key can be used to calculate both child private keys and parent private key.

Extended public keys contain the parent chain code, not necessarily the master chain code, as I explained above. But yes, this is correct.

A child private key is calculated by hashing the parent public key, the parent chain code, and the index, and then adding all of that to the parent private key. If an attacker knows a child private key, as well as the extended public key (which includes parent public key and parent chain code), then the only unknown left in the equation is the parent private key, which can easily be calculated by subtracting the hash we just described from the child private key.

And what about hardened derivation when parent private key is used to calculate child chain code? Then it supposed to be safe to use xpub derived from hardened parent key...

Correct. When using hardened derivation, the parent public key is not used at all in the child key derivation, and so wallets cannot be compromised in the way we've just discussed.

[witcher_sense]

A child private key is calculated by hashing the parent public key, the parent chain code, and the index, and then adding all of that to the parent private key. If an attacker knows a child private key, as well as the extended public key (which includes parent public key and parent chain code), then the only unknown left in the equation is the parent private key, which can easily be calculated by subtracting the hash we just described from the child private key.

I came through Mastering Bitcoin several times, but it is still unclear to me. How exactly does "adding to parent private key" part work? What do we actually add? The result of these addings is supposed to be a child private key corresponding to child public key, right? How is it possible to calculate parent private key from child private key, given that hashing function is one-way function? What if a child private key that was leaked is deep enough from master keys "layer", it is still possible to calculate all the parent keys back to the master key root branch? What equation are you referring to?

[o_e_l_e_o]

What do we actually add?

Let:

k = private key
K = public key
c = chain code
i = index
n = order of the secp256k1 curve

The steps for calculating an unhardened child key are therefore:

Calculate HMAC-SHA512(K_parent, c_parent, i)
Take the left 256 bytes of the result, and add to k_parent (modulo n)

The result of these addings is supposed to be a child private key corresponding to child public key, right?

The result of this calculation is indeed a child private key. You can then turn that child private key in to a child public key in the normal way, via elliptic curve multiplication.

How is it possible to calculate parent private key from child private key, given that hashing function is one-way function?

If you only know the child private key, then it isn't. However, if you know the child private key and the parent extended public key, which includes the parent public key (K_parent) and the parent chain code (c_parent), then you can.

If we simplify the equation above to:

Child private key = Parent private key + Hash

In this scenario, an attacker knows a child private key, and can calculate the hash from the parent extended public key. The only thing he doesn't know is the parent private key. So he rearranges the equation to:

Parent private key = Child private key - Hash

What if a child private key that was leaked is deep enough from master keys "layer", it is still possible to calculate all the parent keys back to the master key root branch?

No. Even if you had leaked your extended public key from every individual level, the hardened levels would stop an attacker progressing all the way to the master keys.