<p>OP_CHECKMULTISIG is typically preceded by:</p>
<ul>
<li>The number of keys (n)</li>
<li>n public keys (not public key hashes!)</li>
<li>The number of signatures required (k)</li>
</ul>
<p>That is not the case here, because the 3 byte arrays that are pushed in between the OP_3 and the OP_1 are not public keys. Public keys are either:</p>
<ul>
<li>33 bytes, starting with 0x02 or 0x03 (so-called compressed public keys)</li>
<li>65 bytes, starting with 0x04</li>
</ul>
<p>The byte arrays pushed here are 65 bytes, but do not start with 0x04.</p>

CC BY-SA 4.0
2022-01-30T16:30:19.913Z
This is `data store` tx https://bitcoin.stackexchange.com/questions/35959/
amaclin
CC BY-SA 4.0
2022-01-30T17:55:31.270Z
Thank you Pieter and amaclin. I should have googled the transaction ID. I assume that it is not possible to spend these outputs as there is not corresponding private keys to enable the OP_CHECKMULTISIG to succeed.

And thank you for correcting my mistake in the original question.
visualAd
CC BY-SA 4.0
2022-01-30T18:12:41.280Z
@visualAd Indeed, it is unspendable.
Pieter Wuille
CC BY-SA 4.0
2022-01-30T13:20:17.373Z
2022-01-30T13:20:17.373Z
Pieter Wuille
<p>I have a question regarding this transaction where the outputs are showing as non-standard but appear to be multi-sigs. This is the first output:</p>
<p>Transaction ID: 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713</p>
<pre><code>OP_1
e4cf0200067daf13255044462d312e340a25c3a4c3bcc3b6c39f0a322030206f626a0a3c3c2f4c656e6774682033203020522f46696c7465722f466c6174654465
636f64653e3e0a73747265616d0a789cad5c4b8b24b911becfafa8b3a1da292925654253d0d55373f06d61c007e39bbd061f0cde8bffbe25c55b5266f61ab3905d
9ba54728e28bb76a963777fbcfb77fdf96db7d291f93f3e599f7fafcedefb73fffe1f6aff665fdefb77f7c7bfefce6c2fa166e695bdfd6dbcfbfddfef8c3dd5cf9
OP_3
OP_CHECKMULTISIG
</code></pre>
<p>Is there an issue with the public key hashes or the script? I am new to this so sure I am missing something simple.</p>
<p>Thank you</p>

CC BY-SA 4.0
2022-01-30T16:27:41.690Z
https://bitcoin.stackexchange.com/questions/35959/
amaclin
<multi-signature>
Non-standard multisig
visualAd
# Non-standard multisig

(Asked by: username_0 on 2022-01-30)

I have a question regarding this transaction where the outputs are showing as non-standard but appear to be multi-sigs. This is the first output:

Transaction ID: 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713

```
OP_1
e4cf0200067daf13255044462d312e340a25c3a4c3bcc3b6c39f0a322030206f626a0a3c3c2f4c656e6774682033203020522f46696c7465722f466c6174654465
636f64653e3e0a73747265616d0a789cad5c4b8b24b911becfafa8b3a1da292925654253d0d55373f06d61c007e39bbd061f0cde8bffbe25c55b5266f61ab3905d
9ba54728e28bb76a963777fbcfb77fdf96db7d291f93f3e599f7fafcedefb73fffe1f6aff665fdefb77f7c7bfefce6c2fa166e695bdfd6dbcfbfddfef8c3dd5cf9
OP_3
OP_CHECKMULTISIG

```

Is there an issue with the public key hashes or the script? I am new to this so sure I am missing something simple.

Thank you

**Tags:** multi-signature

> **Comments:**
> **username_1**: https://bitcoin.stackexchange.com/questions/35959/  

---

## 1 answers

### Answer by username_2 on 2022-01-30. Score: 1 | Accepted answer

OP\_CHECKMULTISIG is typically preceded by:

* The number of keys (n)
* n public keys (not public key hashes!)
* The number of signatures required (k)

That is not the case here, because the 3 byte arrays that are pushed in between the OP\_3 and the OP\_1 are not public keys. Public keys are either:

* 33 bytes, starting with 0x02 or 0x03 (so-called compressed public keys)
* 65 bytes, starting with 0x04

The byte arrays pushed here are 65 bytes, but do not start with 0x04.

> **Comments:**
> **username_1**: This is `data store` tx https://bitcoin.stackexchange.com/questions/35959/  
> **username_0**: Thank you username_2 and username_1. I should have googled the transaction ID. I assume that it is not possible to spend these outputs as there is not corresponding private keys to enable the OP_CHECKMULTISIG to succeed.  And thank you for correcting my mistake in the original question.  
> **username_2**: @username_0 Indeed, it is unspendable.  

---

