I asked claude about it, is it hallucinating?  ->

There seems to be a misunderstanding in that statement. Let me clarify how ECDH (Elliptic Curve Diffie-Hellman) key exchange works, particularly with respect to public key encoding:

In ECDH, the shared secret is computed based on one party's private key and the other party's public key. The result should be the same regardless of which party computes it.
The "02" or "03" prefix in a 33-byte compressed public key encoding doesn't affect the shared secret computation. Here's why:

The prefix (02 or 03) only indicates whether the y-coordinate of the public key point is even or odd.
When decompressing the public key, this prefix is used to reconstruct the full (x, y) coordinates of the point.
The actual ECDH computation uses the full (x, y) coordinates, not the compressed form.


The shared secret in ECDH is typically the x-coordinate of the resulting point from the scalar multiplication of one party's private key with the other party's public key point.
Whether you start with a "02" or "03" prefix, you'll end up with the same full (x, y) coordinates after decompression, and thus the same shared secret.

If you're experiencing different shared secrets based on the prefix, it could indicate an implementation error, possibly in the key decompression step or in the ECDH computation itself.
To ensure correct ECDH implementation:

Properly decompress the public key if it's in compressed format.
Use the full (x, y) coordinates for the ECDH computation.
Use only the x-coordinate of the resulting point as the shared secret.

If you're still encountering issues, it would be helpful to review the specific implementation or library you're using for ECDH computations. 

 it's 1 bit missing, claude is wrong

i literally was getting ~50% error on an ECDH test that used secrets that weren't checked for being even pubkeys

as soon as i made it check for 2 only, fixed 

 now i need to check if go-nostr keygen does it right.. thats typically what ive been using.. 

 spoiler alert: it doesn't check

i just never encountered this before, because it looks like most generators check for a 2 key and either invert it or reject it

it's not specified in either nip-04 or bip-340 except obliquely and not explicitly

you can't get around it, claude is wrong, the ECDH computation makes two different keys depending on whether it's an odd or even Y 

 huh, but it has the pubkey, why wouldnt it be able to know its even or odd when computing shared secret?  im missing something here.. 

 it's not possible for the sender to know the extra bit, they pick the wrong one, the receiver at best could send back a reply "wrong bit" 

 damn 🌋🌊 

 I think it's time to hopefully ask @fiatjaf and maybe @JeffG 

Something seems really wrong. This is nothing that's come up in my tests before. Were all missing something?? This is a huge deal! I beleive this would be part of an EC twist vulnerability... 

 CC @@Magister Michael Dilger M.Sc. @Vitor Pamplona  

 i wasn't aware of what this exactly means, it's not a vulnerability, it's a bug that surely is killing nostr adoption because everyon expects DMs to work, but they obviously can't work without that extra bit

if my dm partners are mostly different sign keys to me, we can't use it 

 BIP-340 specifies choosing the 02.  Look at the section "Implicit Y coordinates" 

 so using code that doesn't check for it is wrong

go read some source code of nostr libraries again with regard to key generation

i'm not gonna pretend i checked the javascript or rust libraries, as i hate both of these languages but the Go libraries DO NOT CHECK

just write a short piece of code generating new keys and then use two of them to make an ECDH key both ways

then you'll know if the library is doing it right