Topic: Determining the positivity or negativity of a Bitcoin public key (Read 350 times)

I saved your contact, I will write to you during the day, thank you

Thank you for your response. Is it possible to communicate with you via private messages? I believe we could find common ground on this topic, but I can't send you a private message because I'm new to this forum.

1. Bitcoin public keys consist of both positive and negative values.

2.Theoretically, tracking Bitcoin private keys can be attempted through factorization, but the numbers involved are too large to make this feasible.

3.If an app existed that could distinguish between the positive and negative aspects of a public key,
all private keys could potentially be discovered within 5 minutes. However, no method for such a distinction has been identified to date.

Here is a site where you can study the basics of positive and negative values:
https://royalforkblog.github.io/2014/09/04/ecc/



Positive:  1×G=(0,2)
Negative: 30×G=(0,27)

Positive: 2×G=(6,17)
Negative: 29×G=(6,12)

This applies to all Bitcoin as well.
Refer to the illustration for more details.
https://ibb.co/y5VjVm5

Hello, I read your post, "Determining the positivity or negativity of a Bitcoin public key," and I find this topic quite interesting. I would like to know what exactly you have discovered on this matter so far, if it’s not too much trouble.

@odolvlobo
@kTimesG

I would like to apologize to both of you.
The part you pointed out as an error was indeed an error.
I was wrong to think that as long as the result was correct, it would be fine.
Thank you to everyone who showed interest.
The issue has been resolved. Thank you!

So you've been told twice already that you're doing things incorrectly, but you insist on it being 100% correct and error-free. Why do you need our opinion in that case?

Public keys for private keys "-1" and N-1 are identical, while your code messes up their compressed representation (since you have a logical contradiction at the reasoning layer, since private keys don't have a sign, since a modular interval doesn't have negative values). So before all else, if your code was Windows 95, this would become a BSOD of the brain.

Since the program itself knows the private key, the public key output result is 100% accurate.
There are no errors in the program.
Please check the private key and the outputted public key.

You code is incorrect. The 0x02, 0x03 prefixes are based only on the value of the public key.

Furthermore, a valid secp256k1 private key is an integer in the range 1 to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140, so testing if it is less than 0 should always return false. If your test returns true, then the private key is invalid or there is a bug in your code.

1. There's no such thing as a negative public key or negative private key.
2. There's no relation between the bits of a private key and the bits of a public key, otherwise ECC would be broken. Your code fails the very fundamentals of how ECC works.
3. You have errors because you wrote that bunch of code without understanding what ECC is all about, and so of course you get errors, since it doesn't make sense even before you would write it on paper as pseudo-code, let alone as a Python script.
4. It works when |pma| > |pmb| because this is how you created it to work (as it doesn't really respect ECC fundamentals, rather some dubious creation of strings which are definitely not respecting the correct private key to public key relation); hence, since it is written in such a way to produce results based on what you wanted it to do, what else would you expect in the other cases? Magic?
5. Good luck on finding a collaborator to help you fix the "errors".
6. Public key prefixes indicate the Y parity (the least significant bit value), not the private key being in the lower or upper half of the scalar field. Else it would be a backdoor/leak in the ECC system. See point 2.

Due to the nature of elliptic curves over finite fields, (when using secure parameters) it is not possible (or at least, no one knows how) to take the public key and infer any information about the private key.

===>
I am not trying to find out the private key; I want a program that can distinguish the positivity or negativity of the public key.

Due to the nature of elliptic curves over finite fields, (when using secure parameters) it is not possible (or at least, no one knows how) to take the public key and infer any information about the private key.

This program generates public keys from randomly created private keys using elliptic curve cryptography, specifically the secp256k1 curve used in Bitcoin. The private keys (pma and pmb) are set with the same sign, either both positive or both negative. Based on the sign of each private key, the program outputs corresponding compressed and uncompressed public keys. The compressed public keys’ prefixes (0x02 or 0x03) are adjusted according to whether the private key is positive or negative.

There is a program that determines whether the private key is positive or negative based solely on the generated public key output.

program

import random
import ecdsa
import binascii

# Define the range
a = random.randint(2**134, 2**135)
am = 10**37
b = a - am

# Set pma and pmb: both values should have the same sign
sign = random.choice([1, -1])  # Set both as either positive or negative
pma = sign * a
pmb = sign * b

# Function to generate a public key from a private key
def generate_public_key(private_key_int):
    # Convert the private key to a 32-byte format
    private_key_bytes = abs(private_key_int).to_bytes(32, byteorder="big", signed=True)
    
    # Generate the elliptic curve public key (secp256k1)
    sk = ecdsa.SigningKey.from_string(private_key_bytes, curve=ecdsa.SECP256k1)
    vk = sk.verifying_key
    
    # Create uncompressed public key format
    public_key_bytes_uncompressed = b"\x04" + vk.to_string()
    
    # Determine the compressed public key's prefix based on the private key's sign
    if private_key_int < 0:
        public_key_bytes_compressed = (
            b"\x03" + vk.to_string()[:32] if vk.to_string()[-1] % 2 == 0 else b"\x02" + vk.to_string()[:32]
        )
    else:
        public_key_bytes_compressed = (
            b"\x02" + vk.to_string()[:32] if vk.to_string()[-1] % 2 == 0 else b"\x03" + vk.to_string()[:32]
        )
    
    # Convert the public keys to hexadecimal strings
    public_key_uncompressed = binascii.hexlify(public_key_bytes_uncompressed).decode()
    public_key_compressed = binascii.hexlify(public_key_bytes_compressed).decode()
    
    return public_key_uncompressed, public_key_compressed

# Generate public keys using pma and pmb as private keys
public_key_a_uncompressed, public_key_a_compressed = generate_public_key(pma)
public_key_b_uncompressed, public_key_b_compressed = generate_public_key(pmb)

# Output the results
print("a:", a)
print("b:", b)
print("am:", am)
print("pma (Private Key a):", pma)
print("pmb (Private Key b):", pmb)
print("public_key_a (Uncompressed Public Key a):", public_key_a_uncompressed)
print("public_key_a (Compressed Public Key a):", public_key_a_compressed)
print("public_key_b (Uncompressed Public Key b):", public_key_b_uncompressed)
print("public_key_b (Compressed Public Key b):", public_key_b_compressed)

It is possible to determine the positivity or negativity if the final output values of pma and pmb from the current program are provided.

When |pma| > |pmb|, the positivity or negativity can be determined with 100% accuracy, but when |pma| < |pmb|, errors occur in determining positivity or negativity. I am looking for someone to collaborate on this issue.