<p>These are not keys, they are arbitrary data.</p>

<p>Until Bitcoin 0.16, an invalid public key was <a href="https://github.com/bitcoin/bitcoin/blob/0.16/src/script/standard.cpp#L135" rel="nofollow noreferrer">allowed in the bare multisig</a>, as long as it's the right size. With the upcoming 0.17, <a href="https://github.com/bitcoin/bitcoin/blob/0.17/src/script/standard.cpp#L81" rel="nofollow noreferrer">this is no longer possible</a>, 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).</p>

<p>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.</p>

<p>A more extreme example of this is in tx <a href="https://www.blockchain.com/btc/tx/fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016" rel="nofollow noreferrer">fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016</a>, which contains "keys" like <code>100000000000000000000000000000000000000000000000000000000000000000</code>.</p>

<p>(example tx from <a href="https://github.com/bitcoin/bitcoin/issues/14104" rel="nofollow noreferrer">this issue</a>)</p>

CC BY-SA 4.0
2018-10-08T09:59:39.597Z
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`?
Andreas Blaesus
CC BY-SA 4.0
2018-10-11T02:55:38.510Z
@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.
Raghav Sood
CC BY-SA 4.0
2018-10-08T09:16:48.363Z
2018-10-08T09:16:48.363Z
Raghav Sood
<p>ECDSA public keys seem to always start with <code>0x02</code>/<code>0x03</code>/<code>0x04</code>/<code>0x05</code> <a href="https://bitcoin.stackexchange.com/a/11301/86692">1</a>, followed by either 32 bytes of 64 bytes.</p>

<p>However, I encounter some public keys prefixed with <code>0x00</code>.</p>

<p>For example, the source output of transaction
<a href="https://www.blockchain.com/btc/tx/5c7c65bb950d3605cc67bd02c29e84cc14dfaa80626ef6a575132c7ce7979d2f" rel="nofollow noreferrer">5c7c65bb950d3605cc67bd02c29e84cc14dfaa80626ef6a575132c7ce7979d2f</a> contains two public keys:</p>

<p><code>037953dbf08030f67352134992643d033417eaa6fcfb770c038f364ff40d761588</code></p>

<p><code>0014fa6851313844da08b6a539aff5e74e705b7465fad0fc5ceeccae707995b846</code></p>

<p>When fed into <code>EC_KEY_oct2key</code> function from OpenSSL 1.1.1, the second public key directly fails.</p>

<p>Another example is transaction <a href="https://www.blockchain.com/btc/tx/f0020466ca75caa648cdc8364f297bda7bb06329bec5305ffb59ea2ea348ac39" rel="nofollow noreferrer">f0020466ca75caa648cdc8364f297bda7bb06329bec5305ffb59ea2ea348ac39</a>, which uses an output that lists a public key like this:</p>

<p><code>0029a38fa2eaf8e67481c47eeeaeb625e6d426eb78f3b9e0728a4679370ce5ac96</code></p>

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

<p>What are these keys and what should a client do with them?</p>

<transactions><public-key><ecdsa>
Why are some public keys prefixed with 0x00?
Andreas Blaesus
# Why are some public keys prefixed with 0x00?

(Asked by: username_0 on 2018-10-08)

ECDSA public keys seem to always start with `0x02`/`0x03`/`0x04`/`0x05` [1](https://bitcoin.stackexchange.com/a/11301/86692), 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](https://www.blockchain.com/btc/tx/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](https://www.blockchain.com/btc/tx/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?

**Tags:** transactions, public-key, ecdsa


---

## 1 answers

### Answer by username_1 on 2018-10-08. Score: 1 | Accepted answer

These are not keys, they are arbitrary data.

Until Bitcoin 0.16, an invalid public key was [allowed in the bare multisig](https://github.com/bitcoin/bitcoin/blob/0.16/src/script/standard.cpp#L135), as long as it's the right size. With the upcoming 0.17, [this is no longer possible](https://github.com/bitcoin/bitcoin/blob/0.17/src/script/standard.cpp#L81), 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](https://www.blockchain.com/btc/tx/fc200f9cef8faf8f76756b5d02081061a1fd22ec1d580f778c12373e12a56016), which contains "keys" like `100000000000000000000000000000000000000000000000000000000000000000`.

(example tx from [this issue](https://github.com/bitcoin/bitcoin/issues/14104))

> **Comments:**
> **username_0**: 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`?  
> **username_1**: @username_0 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.  

---

