Topic: Odd or even? (Read 457 times)

So, first of all I often like to recommend Learn me a Bitcoin for Bitcoin basics.

As we can see, going from private to public key is done through ECDSA. You can read more about the algorithm on Wikipedia. In general, one of the basic requirements of signature algorithms is that they don't leak anything. One such thing would be if it the private key is even or odd, since it would be halving the input space. This would be an instant K.O. for any signature algorithm and nobody would use it.

Yes you can !
but only with this following condition:

1)the public key you have is a raw point (x,y) and not a pubkeyhash (in this case only bruteforce in the range is possible).

2) You had an "oracle" which can tell where is the range of any public key with a precision > 50%. ( 50.000000001% would be ok depending of your power of computation)

It is difficult to answer to your question about a specific algorithm because the algorithm you have to designed depend on the information you can guess on the privkey with the public key

But for example if you can tell if your point is located in the first half or in the second half of N [1,N/2] or in [N/2,N] this is a possible algorithm:


you divide your  point by 2 ( pt' = pt*inv_mod(2,P)) to transfer your point in the upper or in the lower of the range of N as follow :

[1,N/2] if priv (in priv*G) is even:
and
[N/2,N] if priv (in priv*G) if point is odd:

you run your oracle.

with his prediction you can deducte that your initial  privkey is even or odd.
If your oracle is not 100% accurate you repeat the guess with other same point (for example in our case you add 2 on your initial point (to be sure to stay in our range, and to be sure that the new point have the same parity than the initial )  and you rerun your oracle enough times needed  to draw a statistical signifiant trend.

if you know that your priv is odd or even you can use the simple algorithm to decompose a number in binary representation and redo 256 times the process
and that it

Fanch

CrunchyF
A question for you.
If you know how to define the range in which the private key is located.
How can I find out the private key?
What is an algorithm?

P.S. I have previously asked this question on this forum people who also boasted that if you know the range you can find out the private key.
They did not provide answers. (Either they don't know how to brag or they don't want to share.)

If you manage to guess any piece of information (parity , range ,bias,  divisibility by a number etc...) of a private key with his public key  (or a bunch of public keys), secp256k1 will  be broken and bitcoin too.

We are pretty sure (99.9999% but not 100%) that is impossible and the generated public key (EC point)  of a specific private key seems to be perfectly random an perfectly distributed.

Fanch

I realized . Sorry for interfering with the conversation and didn't understand.

Not quite. The 2⁹⁶ private keys in question will produce 2⁹⁶ different public keys. It is the public keys which undergo RIPEMD-160 to produce the same output which will encode to the same address.

So different private keys, different public keys, same address.

There is no reason that two private keys which give an address collision for their compressed public key would also give an address collision for their uncompressed public key, and vice versa.

It wasn't an opinion. Those were facts.

Closed inclusions? Do you use some sort of translator? Because that doesn't make much sense. There are ~2⁹⁶ different private keys that give the same RIPEMD-160 hash, but they each give a unique public key that cannot be generated by any other private key.

o_e_l_e_o
I understood you correctly.
That, according to your words, there are 2-96 private keys.
Which differ from each other.
But form completely the same

Public key
HASH160
.
.
.
.
The address compressed and uncompressed.

Everything is correct  ?

Each private key corresponds to one public key. That public key can expressed in two ways - compressed and uncompressed - but they both refer to the same point on the curve. There are almost 2²⁵⁶ possible private keys, and the same number of possible public keys (or double that if you count compressed and uncompressed public keys separately).

There are only 2¹⁶⁰ possible P2PKH addresses though, since to reach an address you must use the RIPEMD-160 function, which outputs a 160 bit result. So there are in the region 2⁹⁶ possible different private keys which will all give the same address (and again, more than that if you consider compressed and uncompressed public keys separately).

Gentlemen.
pooya87
HeRetiK
BlackHatCoiner
I appreciate your opinion and your position on the curve.
But, there are at least on the curve, two private keys that are completely different from each other. At the same time they form identical (identical)
Public key
HASH160
.
.
.
.
The address  compressed and uncompressed.




But, in my opinion, there are 4 such keys. Which can be different, and at the same time form the same source data, up to the address itself.

P.S.
I can't prove the theory of 4 keys now, I'm working on it. In free time from work.

Take any number you want and solve the equation y² = x³ + 7 mod p. You'll realize that there are two points that have the same x coordinates, but different y coordinates. These are considered different public keys.

Form the same public key or address?

I believe you may be confusing deriving the public key from the private key and deriving the address from the public key? Apologies if you are referring something else entirely.

A public key P(x,y) is computed from one and only one private key.
Keep in mind that P(x,-y) is computed from a different private key too which is equal to n-k.

You are all wrong.
There are at least two different private keys that can be generated, one and the same public key and everything related to it, to the address itself.
But, in my opinion, there are four different such keys. Which can form all the same.

You are gravely mistaken. One private key corresponds to exactly one public key, and vice versa.

Each P2PKH and P2WPKH address could correspond to about 2⁹⁷ or 2⁹⁶ keys.

Finding out if private key is even or odd is equivalent to solving ECDLP, which currently takes about 2¹²⁸ curve operations.

I had seen this asked before. What for? What can you achieve by excluding half of the available private keys?

This is false. You've confused it with the address. A public key can only be generated by one private key.

To answer to this question, there is no need to mathematical calculations at all. The answer is the same for any public key.
Any public key can be generated by 2^96 private keys on average. Therefore, any known public key can be generated by numerous odd private keys and numerous even private keys.  

Sorry, there is exactly 1 private key for any public key.

No. The public key is derived from the private key by multiplying a point on the secp256k1 curve by your private key.

The "curve" on the secp256k1 curve is not a curve that you would see in a circle. If you were to see its points plotted on a graph, it would look more like random points to most people.

It is not possible to divide by a point on the secp256k1 curve, and as such, you cannot calculate the mod 2 of the private key.

Good day!

I think  that answer is NO, but maybe..

Is there any ways to understand is private key of known public key odd or even? Maybe any mathematician operations with public keys may helps?

Thank you!