jonasnick
commented
6 months ago The scope of the library is defined in CONTRIBUTING.md. In particular, we recommend a specification and providing arguments for relevance in the Bitcoin space. I think a vague potential future upgrade to Bitcoin does not give sufficient evidence for relevance alone and would in practice put an eventual PR near the bottom of the priority list. If a future upgrade was concrete and with community support, of course this changes considerations.
I generally agree that a BIP 340-variant with 32-byte public keys + parity bit can be useful in some situations to avoid the need for parity bit tracking in more complex protocols such as MuSig2. But as long as Bitcoin consensus uses BIP 340, I don't see a particularly high demand for such a scheme right now.
JeremyRubin
real-or-random
According to BIP-340, XOnly keys have 32 bytes and signatures have 64 bytes.
If X + Parity is used, signatures would be 65 bytes and Keys 33 bytes. Really, they just require one bit, but the minimum encoding unit is 8 bits, so there is 7 bits waste.
It would be useful to include a reference implementation here of X + Parity Schnorr signatures. A future upgrade to Bitcoin might choose this encoding. I'm not super familiar with this codebase, but perhaps if it is conceptually ACKd to include this in secp256k1, myself or others might do the work (v.s. if it's guaranteed to be rejected).