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:



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:


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?

1 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)

  • Thanks! A follow-up question: is disallowing invalid public keys an effective defense against this particular trick? As most 32-byte data are valid coordinates anyways, wouldn't it be rather straightforward to circumvent this restriction by using prefixing the arbitrary data with 0x02 or 0x03? Commented Oct 8, 2018 at 9:59
  • @AndreasBlaesus Indeed, it is not a great defense. I haven't had time to check the code to see if it does any deeper checking (although I don't believe it can, off the top of my head). The change however does make it a standardization rule. Commented Oct 11, 2018 at 2:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.