I have a question about bitcoin privkey: If you have TWO pair privkey(compressed and uncompressed) I wrote again TWO pair, yes i know, many person say - it is not possible, but...

And this works with many other address, can anyone can make algorithm for compute privkey from pubkey

Pubkey is the same for both pair

  • 1
    $\begingroup$ I'd point the asker towards Bitcoin Stack Exchange, but honestly, this question is so vague and poorly written that I doubt it'd be any better received there, either. $\endgroup$ – Ilmari Karonen Jan 5 '18 at 18:42
  • $\begingroup$ It is simple... If you have TWO pair privkey(compressed and uncompressed) I wrote again TWO pair, can you make algorithm for compute privkey from pubkey. $\endgroup$ – Mikan Jan 5 '18 at 19:26
  • $\begingroup$ When you say "two pair privkey", what do you mean? You have two key pairs that have the same private key? And both have been used for signatures or what? $\endgroup$ – mikeazo Jan 5 '18 at 20:08
  • $\begingroup$ Let's say someone have two diferent uncompressed and two compressed key pair, and both can be used for signature, and pubkey is the same $\endgroup$ – Mikan Jan 5 '18 at 20:18

Clarifying what is what

First of all: there is a difference between the way a compressed Bitcoin key and an uncompressed Bitcoin key is encoded.

So, a private key will never result in a compressed public key and an uncompressed public key that are exactly the same. Chances for this happening are close to zero.

Similar is true for compressed private keys and uncompressed private keys, due to the way they are encoded.

And then there's the fact that an elliptic curve public key is different from a compressed/uncompressed Bitcoin public address.

Diving into your question

The chance that

Pubkey is the same for both pair

is so low that I am pretty sure that

  1. If you're talking about the ECDSA public key, then either your public key generation function is faulty (meaning: you are using a faulty elliptic curve implementation), or
  2. you found a glitch in the elliptic curve itself which would be worth publishing. But this is highly unlikely, especially since you state this to be the same for multiple compressed as well as uncompressed private/public keypairs (which again sounds more like a faulty elliptic curve implementation), or
  3. if you are instead talking about the Bitcoin address (which sometimes is falsely called "public key" too), then you found a "one-in-a-million" collision… spanning two completely different hash algos (SHA-256 and RIPEMD-160) which would be a primer worth publishing. Yet, this is so unlikely that I'm pretty confident this is not the case either.

Which finally brings us to the core of your question:

can anyone can make algorithm for compute privkey from pubkey


First up, one reason is that elliptic curve crypto is build to make that hard. Being able to reconstruct a private key from an elliptic curve public key would equal being able to break elliptic curve cryptography for the curve Bitcoin uses. (And it does not matter if its compressed or uncompressed, since compressed versions merely allow shorter notation.)

If you then look at the fact Bitcoin doesn't use the elliptic curve public keys directly but instead Bitcoin addresses which are generated by additionally using RIPEMD-160 and SHA-256 hashes (think: one-way compression functions), you're talking about a scenario I regard to be nonexistent.

BTC address to ECDSA public key

To be able to generate the private keys from public Bitcoin addresses, you would need to be able to revert cryptographically secure hashes back to their input — which is not possible for the two hash functions used. Also, a hash digest generally does not contain enough data to reconstruct its input from the digest — hence the name "digest".

ECDSA public key to private key

Even if you would — by sheer magic — be able to reconstruct the input $x$ of an $\text{RIPEMD160}(\text{SHA256}(x))$ function, you'ld then have to break ECDSA (Elliptic Curve Digital Signature Algorithm) to reconstruct the private ECDSA key from the reconstructed $x$.

If that were possible, ECDSA would be broken and immediately rendered insecure… with according consequences to hundreds of use-cases out there. At the time of writing this answer, no such weakness is known.

Further reading

For a more detailed view on how a Bitcoin address is generated from an elliptic curve public key, check this:

btc pubkey gen

image source: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses

An explanation how you get an elliptic curve public key from a private key is more complex and would be too broad for an answer here. Yet, there are other Q&As at our site handling that, so take a look around to learn more about that. Same goes for how ECDSA works. And how SHA-256 and RIPEMD-160 work, and why it's infeasible to reconstruct the input from their output, is also handled in multiple Q&As at this site.


compute privkey from pubkey

is infeasible for the reasons described above.

  • $\begingroup$ Thank You for answer. Now can you explain me how it is possible? This is only example: Privkey1: 1111111111111111111111111111111111111111111111111111111111111111 Pubkey: 044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1 Privkey2: ???????????????????????????????????????????????????????????????? Same Pubkey: 044f…1c1 Where ???… is different from privkey1. This is valid privkey, we can used for signed message. How can you explain that? $\endgroup$ – Mikan Jan 6 '18 at 8:13
  • $\begingroup$ and if i tell you something impossible, I'm not realy sure, I can't verify everything, but that probably is something about 10^39 address. I know it's creazy, but....WHAT IF...? $\endgroup$ – Mikan Jan 6 '18 at 8:35
  • $\begingroup$ Note that we generally tend to handle “What if ______ happened?” Qs as off-topic. Anyway, when you write $10^{39}$ you're thinking about a chance of 1 in which is why it’s called “infeasible” and/or “highly improbable”. Actually, the real chance in BTC would be about $\frac{1}{2^{37}}$. For comparison: there are about $2^{32}$ seconds in a century. That’s why I wrote that – if you would actually find such two privkeys resulting in the same pubkey, you would have a finding worth publishing. $\endgroup$ – e-sushi Jan 7 '18 at 21:42
  • 1
    $\begingroup$ In the unlikely case you indeed have an alike ECDSA finding and you don't know where or how to publish it, simply tell me and I'll help. But you'ld need to share the actual private keys producing that 044…1c1 pubkey you posted. Since privkeys are binary, I expect the usual HEX representation (not some ? string) to verify things. Also, I need a copy of the software/code. After all, first step is to ensure your finding is not a software-related bug, and that the finding is indeed correct, genuine, and reproducible. Otherwise, I’ll continue to simply classify this as a nonexistent scenario. $\endgroup$ – e-sushi Jan 7 '18 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.