Hey folks,
I wanna throw a challenge out there for everyone.
Check out this constant:
0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1
The challenge is simple: given a random private key, can you tell if it's greater than or less than this constant?
But here's the catch, it's not just about guessing (which gives you a 50/50 chance). We're talking about whether there's any mathematical or cryptographic logic that can help you consistently find the answer.
To lay it out more clearly:
Imagine you’re presented with 100 of these comparison questions.
Is there anyone here who could get all 100 right without relying on luck?
This challenge has two aims:
1. To see if there's known logic or methods that can solve these consistently.
2. To determine if, based on what we know now, it's just impossible without guessing.
If you think there's a method that works, share your thoughts or approach. And if you think it can't be done, just saying so would also be helpful.
Looking forward to your ideas and input.
No.
No.
As long as secp256k1 is strong, there is no method to do that. And also, you miss one important thing: the private key depends strictly on the picked generator. For example: let's assume, that you pick some private key:
Then, it is obviously in the upper half. However, let's assume, that you would use two times bigger point as your new G:
And then, suddenly, your "newD" is in the lower half, while "d" is in the upper half. And both are leading you to the same public key Q. So, if you look at public key Q alone, is the private key in the upper or lower half? The answer is: it depends on the base point you pick.
Which means, that if you try to find some function, like:
Then it is not enough. You need something like that instead:
And for secp256k1 it is very unlikely, that you will write some working implementation. However, for smaller curves, it is possible to write a brute force search, which will give you the exact answer. Instead of secp256k1, try these curves first: https://bitcointalk.org/index.php?topic=5459153.0
A private key is an integer and your constant is also an integer so you can perform a simple comparison to see which one is bigger. But if by "the key" you mean the "public key" then it is impossible because as it was mentioned the whole underlying cryptography would have been deemed broken and people would have been able to start solving the ECDLP!
Fair enough You have a good point. A private key is just a gigantic number so comparing it to another number is kinda straightforward. But a public key isn't a number it's more like a point on a specific mathematical curve. Think of it like comparing a number to a physical street address they are fundamentally different kinds of data.
it's easy to get from your private key (the number) to your public key (the point on the curve), but it's computationally impossible to go back. If you could somehow compare a public key to an integer in a way that gave you a clue about the original private key you basically would have just turned that one way street into a two way street and the whole system would crumble.
It is not possible to reverse all public keys, but with my special program, I can determine 100% whether the result is "over" or "under." Please try creating a challenge. After running the program, just post the part of the output starting from
--- Public Keys for Each Challenge ---
and I will predict whether it is "over" or "under" within one hour.
I want to emphasize once again: not every public key in existence can be solved, but with the program I provided, it seems possible to do so.
The code below is broken. That's not how compressed public keys are formatted.
The public key prefix is determined only by the low-order bit of the Y component. It is unrelated to the high-order bit of the private key.
It's odd that you continue making this mistake after you acknowledged it here (https://bitcointalk.org/index.php?topic=5518307.msg64748160#msg64748160) when I previously pointed it out.
Treating a private key as positive or negative is not useful. Private keys are in the range 1 to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140. You could consider a private key with the high bit set (those greater than 2255-1) as being negative, but there is no purpose for doing that because ECC does not recognize negative private keys.
Here is a sorted list of 100 randomly-generated compressed public keys. Exactly 50 have private keys that are less than your constant and exactly 50 have private keys that are greater. So, if you do not get 50/50, you will know something is wrong.
Good luck!
By the way, I did not use your generation code. I see no reason why that would change the results. Here is the script I used to generate the private keys and derive the associated compressed public keys:
I would like to clarify that I cannot solve the problem as it was originally presented.
In my program, the condition (pma) > (pmb) must hold true for the results to be valid.
Currently, I am working under the assumption that am = (10**37) == (pma - pmb), and this relationship must be satisfied for correct outcomes.
The reason I am posting this on the forum is not to boast about what I can do,
but rather to find a partner who can work with me on discovering a method to derive pmb from pma.