Will `jivsov-ecc-compact-05` work for `secp256k1`, or only for NIST curves? #1248

Apple's swift-crypto has support for serialisation of PublicKey to/from X-only, for NIST curves (P256, P384 and P521), using this technique in "Compact representation of an elliptic curve point" from 2014. Does that only work for NIST curves, or would that work for SECG curves, specifically secp256k1 as well?

I cannot see how it would work, without the parity bit... but isn't NIST curves also symmetric alongside the x-axis? i.e. for any point on the curve, there exist a "mirror" point on the otherside of the X-axis (apart from point at infinity)

If it works for secp256k1 we should perhaps add support for it, what it would mean is that we could parse a secp256k1_pubkey from a secp256k1_xonly_pubkey (or otherwise the 32 bytes of the x component), right?

Yes, this IETF draft seems to be nearly identical to our scheme, except it uses "low y" as a parity split rather than using parity (or Jacobi symbol). It doesn't seem to consider either of these techniques, even though our scheme is a bit faster for any prime-order curve.

As you are hinting at, it does this by simply eliminating half the keyspace from consideration, which is also what we do with our x-only keys. You "deserialize" to a full public key by fixing the parity to 0, which is what our library does internally to do signature verification etc (modulo our different notions of "parity").

But nonetheless, for some applications of keys (for example Taproot tweaking), you can't effectively force the parity to 0 (excet by the "black box" technique where you do exponential work in the number of points you need to produce, and where you are SOL if all your inputs are deterministic) and you also need the parity to do computations. So we can't move to a world where everything is x-only and we pretend that the parity bits don't exist ... although I think we all hoped for that early on, and we've heard from external developers e.g. in Lightning that they wished this were true.

Thank you for the explanation @apoelstra ! 🥳