Topic: same private key? - page 2. (Read 1717 times)

Thank you for the corrections, but I personally prefer avoid strong adjectives when it comes to questions about odds, sometimes I fail and use "infeasible" insted of "extremelly unlikely" and "almost impossible". If it can happen, it will happen, this is how I see it. It may be that knowing bitcoin address provides zero help, but at least it gives some information to an attacker: existence of UTXO and amount of bitcoin. Address is now active and therefore more interesting than empty, inactive ones. Still, with the current computation power, it is impossible to crack specific address. But what if an attacker is not interested in specific address, but in all addresses with balance. I have heard of so-called "bitcoin collider" pools where they create a list of known bitcoin addresses with funds and then searching for collisions. What they do is simply a calculating of bitcoin addresses: private key -> public key -> address and comparing them with the list of known addresses. It looks like stupid waste of energy, but sooner or later they may find something.

It is true that the private key cannot be the same, the creators of bitcoin do not play in maintaining security, of course with the expensive price of bitcoin the security key is tightly secured, randomized from the numbers 1 to 9 and from the letters A to Z there is definitely nothing the same.

Bitcoin private keys cannot be the same from one person to another because Satoshi Nakamotor has designed the best possible private key generation, because the random private key generation for words from 1 to 9 and from a to z cannot be the same, so everyone will have one private key each

Importantly, an address also includes a checksum.

Knowing an address provides exactly zero help when it comes to bruteforcing a public key, and knowing a public key provides exactly zero help when it comes to bruteforcing a private key. An attacker would still have to exhaust half the search space, on average.

It is not hard to reverse a hash function - it is impossible.

A hash function is not encryption.

 ?yes but what for how do you suppose to use it

I don't know and have never experienced that, because in my opinion it is impossible based on this key type the same as the encryption model that the blockchain has with sha256. But based on what some users say "possible", is there any concrete information about the private key model of the wallet? Especially if we see that the combination of numbers, lowercase and uppercase can make more than a million results.

https://keys.lol/
Try your luck if you don't understand what 2²⁵⁶ means.

Then read this
https://www.reddit.com/r/Bitcoin/comments/1ohwvu/bitcoin_your_money_is_secured_by_the_laws_of_the/ccs5g52/
and this
https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/

I wouldn't worry about someone generating the same key

Yes, if someone like you gets the same private key then that person will have complete control over your wallet. But in reality it is impossible to generate the same private key and the same bitcoin address. Take care of your personal key and never try to share it with others so that you do not have access to your wallet. Otherwise the fraudster will spend all your funds.

You normally never see or deal with private keys or public keys while using your HD-wallet. Bitcoin address is not the same thing as public key. In essense, bitcoin address is a result of double hash of your public key. In case an attacker knows your bitcoin address, he first needs to bruteforce your public key and only then he can start bruteforcing your private key. It is kind of double defense system, however it is hard to unhash hashes and infeasible to "calculate" elliptic curve multiplication back.

Absolutely. It's called elliptic curve multiplication. In short, you multiply the private key by the generator point of the secp256k1 curve. The generator point is a fixed value, and is the same for every person and every key, so the same private key multiplied by the generator point will always result in the same public key.

Private keys are only 51-52 characters when they have been converted to Wallet Import Format (WIF). A raw private key is 64 characters of hexadecimal.

In total there are a little under 2²⁵⁶ possible private keys, a little under 2²⁵⁶ possible public keys, and exactly 2¹⁶⁰ possible addresses. Therefore, no two private keys will lead to the same public key, but multiple public keys (and therefore private keys) can lead to the same address.

Guessing the private key from knowledge of only the public key is impossible.

Sorry for hijacking a bit, I know the Public key is associated with the private key so wherever I use the private key, I get the same public key.
Is there a specific way of defining the Public key from a private key?
As private key are longer (51-52) and public keys shorter, is there any chances that a different set of private key be associated with same public key.
Furthermore, if there's an association between public and private key, would it make easier to guess the private keys from the public key?

no, it doesnt

a forum or website checks a new username against its database to see if its used. if it is, you are promoted to choose a different one. a private key is just a random number. what generates that private key (a program, dice, cards, coin flips, radioactive decay, whatever) doesnt check to see if its used. its just astronomically high that you generate a private key thats "used" already.

most likely impossible, as you explain
but it can happen if there are bugs and this possibility is very small
privatekey works like a username where there is very little chance of the same username on a website unless there is a bug

Private key is a random binary number, which is used to spend your bitcoins corresponding to that private key. Imagine your bitcoins stored in safe deposit box and in order to open it you have to use your own key. That key is your private key, binary number. That number is not stored inside blockchain, it is stored inside your encrypted wallet, protected by password. In order to send bitcoins somewhere, you have to sign a transaction with your own key. You literally open your deposit box and hand over coins to another deposit box, which could be owned by you or another person. In order to achieve maximum security and privacy, you never reuse your old deposit box. The technology used to generate your safe deposit box key is so unique that it is nearly impossible to create identical keys, so you can be sure that you are the only one who controls your own deposit box.

That would not be possible since every Private key made is unique and having the same private key would be a breach in security. The blocks where they are stored are also different and since there are a lot of wallets being made daily, there have been no issue regarding the same private key. Blockchain Technology boasts its security regarding these kinds of matter and that is why the same private key won't be produced.

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

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

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.

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?

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.

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.

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.

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.

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

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.