<p>Looks like it's related to 
<a href="https://github.com/bitcoin/bitcoin/blob/master/src/pubkey.h#L48" rel="nofollow">https://github.com/bitcoin/bitcoin/blob/master/src/pubkey.h#L48</a>.</p>

<p>As far as I've understand (also thanks to #bitcoin @ freenode users) the pubkeys I was trying to decode didn't match this check, so, for the records: in the examples mentioned, the addresses array (and the reqSigs int) is populated only when the first byte of the pubkey match the checks for the relative length (compressed or not).</p>

CC BY-SA 3.0
2015-08-12T07:37:21.007Z
2015-08-12T07:37:21.007Z
Guido
<p>tx: 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1</p>

<pre><code>OP_1
04cc71eb[...cut...]0d348ac4 // this is pubkey of 1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F
0461cbdc[...cut...]c15342af // this is pubkey of 1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq
OP_2
OP_CHECKMULTISIG
</code></pre>

<p>to spend this transaction one should sign it with one-of-two privkeys</p>

<hr>

<p>tx: 274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857</p>

<pre><code>OP_1
0351efb6[...cut...]77da78 // this is public key of 1NdB761LmTmrJixxp93nz7pEiCx5cKPW44
00f2b781[...cut...]93569e // this is not a public key!
OP_2
OP_CHECKMULTISIG
</code></pre>

<hr>

<p>tx: 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17</p>

<p>You can read about this transaction here: 
<a href="http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html" rel="nofollow">http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html</a> [16]</p>

CC BY-SA 3.0
2015-08-11T19:28:59.220Z
2015-08-11T19:28:59.220Z
amaclin
<p>I used to think the addresses array into the scriptPubKey (vout) is populated starting from the script, but examining old-fashion multisig transactions, I discovered something made my assumption wrong:</p>

<p>Given this three vouts:</p>

<pre><code>{
    "value" : 0.01000000,
    "n" : 0,
    "scriptPubKey" : {
        "asm" : "1 04cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4 0461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af 2 OP_CHECKMULTISIG",
        "hex" : "514104cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4410461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af52ae",
        "reqSigs" : 1,
        "type" : "multisig",
        "addresses" : [
            "1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
            "1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq"
        ]
    }
}

{
    "value" : 0.00000002,
    "n" : 0,
    "scriptPubKey" : {
        "asm" : "1 0351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da78 00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e 2 OP_CHECKMULTISIG",
        "hex" : "51210351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da782100f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e52ae",
        "reqSigs" : 1,
        "type" : "multisig",
        "addresses" : [
            "1NdB761LmTmrJixxp93nz7pEiCx5cKPW44"
        ]
    }
}
</code></pre>

<p>which comes respectively from transactions:</p>

<p>60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1
274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857</p>

<p>I have noticed that they share the same script:</p>

<p>OP1 OPDATA OPDATA OP2 OP_CHECKMULTISIG</p>

<p>but with different results.</p>

<p>In the first one transaction you can see two addresses in the addresses array, in the second one you can see only an address.</p>

<p>Also, given this one:</p>

<pre><code>{
    "value" : 0.00000001,
    "n" : 22,
    "scriptPubKey" : {
        "asm" : "1 6565292c66696c653d7379732e737464657272290a0a69662046616c73653a0a202020207072696e742870726f78792e73656e647261777472616e73616374696f 6e287369676e65645f74785b27686578275d29290a656c73653a0a202020207072696e74287369676e65645f7478290a0000000000000000000000000000000000 2 OP_CHECKMULTISIG",
        "hex" : "51416565292c66696c653d7379732e737464657272290a0a69662046616c73653a0a202020207072696e742870726f78792e73656e647261777472616e73616374696f416e287369676e65645f74785b27686578275d29290a656c73653a0a202020207072696e74287369676e65645f7478290a000000000000000000000000000000000052ae",
        "type" : "multisig"
    }
}
</code></pre>

<p>which comes from transaction 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17</p>

<p>No reqsigs nor addresses comes in the parsed transaction.</p>

<p>So, I think I am a little confused on how addresses array is populated.</p>

<multi-signature>
Understanding basic Bitcoin Transactions: the scriptPubKey.addresses array
Guido
# Understanding basic Bitcoin Transactions: the scriptPubKey.addresses array

(Asked by: username_0 on 2015-08-11)

I used to think the addresses array into the scriptPubKey (vout) is populated starting from the script, but examining old-fashion multisig transactions, I discovered something made my assumption wrong:

Given this three vouts:

```
{
    "value" : 0.01000000,
    "n" : 0,
    "scriptPubKey" : {
        "asm" : "1 04cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4 0461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af 2 OP_CHECKMULTISIG",
        "hex" : "514104cc71eb30d653c0c3163990c47b976f3fb3f37cccdcbedb169a1dfef58bbfbfaff7d8a473e7e2e6d317b87bafe8bde97e3cf8f065dec022b51d11fcdd0d348ac4410461cbdcc5409fb4b4d42b51d33381354d80e550078cb532a34bfa2fcfdeb7d76519aecc62770f5b0e4ef8551946d8a540911abe3e7854a26f39f58b25c15342af52ae",
        "reqSigs" : 1,
        "type" : "multisig",
        "addresses" : [
            "1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
            "1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq"
        ]
    }
}

{
    "value" : 0.00000002,
    "n" : 0,
    "scriptPubKey" : {
        "asm" : "1 0351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da78 00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e 2 OP_CHECKMULTISIG",
        "hex" : "51210351efb6e91a31221652105d032a2508275f374cea63939ad72f1b1e02f477da782100f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e52ae",
        "reqSigs" : 1,
        "type" : "multisig",
        "addresses" : [
            "1NdB761LmTmrJixxp93nz7pEiCx5cKPW44"
        ]
    }
}

```

which comes respectively from transactions:

60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1
274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857

I have noticed that they share the same script:

OP1 OPDATA OPDATA OP2 OP\_CHECKMULTISIG

but with different results.

In the first one transaction you can see two addresses in the addresses array, in the second one you can see only an address.

Also, given this one:

```
{
    "value" : 0.00000001,
    "n" : 22,
    "scriptPubKey" : {
        "asm" : "1 6565292c66696c653d7379732e737464657272290a0a69662046616c73653a0a202020207072696e742870726f78792e73656e647261777472616e73616374696f 6e287369676e65645f74785b27686578275d29290a656c73653a0a202020207072696e74287369676e65645f7478290a0000000000000000000000000000000000 2 OP_CHECKMULTISIG",
        "hex" : "51416565292c66696c653d7379732e737464657272290a0a69662046616c73653a0a202020207072696e742870726f78792e73656e647261777472616e73616374696f416e287369676e65645f74785b27686578275d29290a656c73653a0a202020207072696e74287369676e65645f7478290a000000000000000000000000000000000052ae",
        "type" : "multisig"
    }
}

```

which comes from transaction 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17

No reqsigs nor addresses comes in the parsed transaction.

So, I think I am a little confused on how addresses array is populated.

**Tags:** multi-signature


---

## 2 answers

### Answer by username_0 on 2015-08-12. Score: 1

Looks like it's related to
<https://github.com/bitcoin/bitcoin/blob/master/src/pubkey.h#L48>.

As far as I've understand (also thanks to #bitcoin @ freenode users) the pubkeys I was trying to decode didn't match this check, so, for the records: in the examples mentioned, the addresses array (and the reqSigs int) is populated only when the first byte of the pubkey match the checks for the relative length (compressed or not).


---

### Answer by username_1 on 2015-08-11. Score: 1

tx: 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1

```
OP_1
04cc71eb[...cut...]0d348ac4 // this is pubkey of 1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F
0461cbdc[...cut...]c15342af // this is pubkey of 1A8JiWcwvpY7tAopUkSnGuEYHmzGYfZPiq
OP_2
OP_CHECKMULTISIG

```

to spend this transaction one should sign it with one-of-two privkeys

---

tx: 274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857

```
OP_1
0351efb6[...cut...]77da78 // this is public key of 1NdB761LmTmrJixxp93nz7pEiCx5cKPW44
00f2b781[...cut...]93569e // this is not a public key!
OP_2
OP_CHECKMULTISIG

```

---

tx: 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17

You can read about this transaction here:
<http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html> [16]


---

