yeah, woo, it's a crapshoot
i rewrote my test to see how often it failed
50% +/- 1%
so, you have to sometimes add a 0x02 to the front of BIP-340 pubkeys, and sometimes 0x03
you can only really check this if you know the secret or if you have a valid signature to try both on
ok, so hmm now what
both the ways i am thinking through this result in extra computation
so, in my code i have an ECDH generation, doing this for nip-04/nip-44 implementation
the magic is that if i put a 02 in front (even pubkey) and it fails, if i switch that for a 03 in front, and it passes, then that is correct
my measurements so far show that on average, using only the 02 fails 50% of the time, unsurprisingly, as it is literally a coinflip
so, how do i do ecdh with x-only pubkeys
there has to be a preliminary test to it, i mean, the ECDH derivation using x-only pubkeys implicitly needs to produce two possible secrets, and one will be correct if the pairs are correct
ok, i think i can deal with this, just write an ec derivation that gives back the two options, and then OR the comparisons of these with the candidate, and if true, done
ok, this is complicated though
it makes it more complicated on the decode... is there sentinels in the plaintext that i will get when i prode the ciphertext that i can positively verify and determine whether it needs to be odd or even
oh well, for testing anyway, just gonna revise the API to return the two possible secrets based on the x-only pubkey in an ecdh
i know that the secret can't be wrong, so one of the public keys will be wrong, and if both are wrong, then it fails
