Avoid public keys starting with `02`, `03` and `04` bytes #1060

Currently when doing stream deserialization it will be impossible to guess serialized key format without using special dedicated tag. It was not the case with previous deserialization for compressed/uncompressed Secp keys since the first byte uniquely defined key length and format. Here I propose to avoid use of public keys starting with 02, 03 and 04 bytes to avoid such ambiguity and make keys deserializable from I/O stream without the need for custom encoding prefiexes and additional standards for wallets.

NACK, needing to change derivation functions is a huge pain, as it intersects several layers.

If you need a way to serialize keys in a place where they could be confused with SEC1-encoded keys, why not just use that directly (i.e. prefix them with 0x02), or invent a new prefix to mean "BIP340 key follows"?

If you need a way to serialize keys in a place where they could be confused with SEC1-encoded keys, why not just use that directly (i.e. prefix them with 0x02), or invent a new prefix to mean "BIP340 key follows"?

Because this will be a non-standard way, and different software will end up using different prefixes.

I agree with that changing derivation function is crazy. Maybe make a non-consensus Schnorr key serialization prefix (let's say 01) part of this standard?

I have faced this problem when was working on rust-bitcoin new PublicKey type that will be an umbrella type for all possible bitcoin public keys as was originally discussed with @apoelstra in https://github.com/rust-bitcoin/rust-bitcoin/issues/554

I think this is a terrible idea, sorry. Just keep metadata around in your type to know what encoding to use. This shouldn't leak into the specification of the BIP340 key type or its usage.