Why are some public keys prefixed with 0x00?

Question

ECDSA public keys seem to always start with 0x02/0x03/0x04/0x05 1, followed by either 32 bytes of 64 bytes.

However, I encounter some public keys prefixed with 0x00.

For example, the source output of transaction 5c7c65bb950d3605cc67bd02c29e84cc14dfaa80626ef6a575132c7ce7979d2f contains two public keys:

037953dbf08030f67352134992643d033417eaa6fcfb770c038f364ff40d761588

0014fa6851313844da08b6a539aff5e74e705b7465fad0fc5ceeccae707995b846

When fed into EC_KEY_oct2key function from OpenSSL 1.1.1, the second public key directly fails.

Another example is transaction f0020466ca75caa648cdc8364f297bda7bb06329bec5305ffb59ea2ea348ac39, which uses an output that lists a public key like this:

0029a38fa2eaf8e67481c47eeeaeb625e6d426eb78f3b9e0728a4679370ce5ac96

These 0x00 public keys seem to always come with OP_CHECKMULTISIG and never block validation because some other public key would be valid.

What are these keys and what should a client do with them?

Answer 1

These are not keys, they are arbitrary data.

Until Bitcoin 0.16, an invalid public key was allowed in the bare multisig, as long as it's the right size. With the upcoming 0.17, this is no longer possible, and transactions like the ones you linked to will be considered non-standard (note that this does not prevent their inclusion in a block, and they are still valid if included).

People have often used such tricks to embed data in the blockchain. For instance, providing 1 valid and 1 invalid key in a 1 of 2 multisig allows someone to embed 33 bytes of data, without sacrificing the BTC locked up in the wallet.

A more extreme example of this is in tx fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016, which contains "keys" like 100000000000000000000000000000000000000000000000000000000000000000.

(example tx from this issue)