<p>Yes, this tx has only the signatures in the V_IN part (unlocking script), no public keys directly behind it, or a redeemscript. The V_OUT part (locking script) has a redeemscript for a 2-of-3 multisig. Usually one would expect a redeemscript hash in the pubkeyscript, but here it is the plain hex codes. 
So it is an old type multisig (not using P2SH). The unlocking script is the two signatures, and locking script provides the required pubkeys. </p>

<p>So what would happen on the stack:</p>

<p><code>&lt;sig1&gt;</code></p>

<p><code>&lt;sig2&gt;</code></p>

<p><code>&lt;redeem script data&gt;</code> ("2" pk1 pk2 pk3 "3" CHECK_MULTISIG)</p>

<p>In a first step the unlocking script is executed, and if valid (results in a TRUE value, or no remaining operators remain on the stack), the tx would be marked as valid. It only pushes data (the signatures), so ok. Then the second step would clear the stack, and sigscript and pubkeyscript would be pushed and executed. As one can see, the three elements on the stack can be resolved to TRUE, and as such it is a simple multisig. 
Decoding the pubkeys in the redeem script shows:</p>

<pre><code>5221037BF122821AE522F67B7BC09387C2907607CDD66E6BD67BCB53F39D5346ADC74821033E81519ECF373EA3A5C7E1C051B71A898FB3438C9550E274D980F147EB4D069D21027AA4A8DAFFF9B6307899BB7762BF92C50ABDE14C3636719FFC4D4FABF3DC6B0F53AE

    52: OP_2
    21: OP_Data21 (= decimal 33)
        037BF122821AE522:F67B7BC09387C290
        7607CDD66E6BD67B:CB53F39D5346ADC7
        48
        bitcoin address:   18pvHhDLrGJpJ7SznnoxxFdwPnKCqjqVCj
    21: OP_Data21 (= decimal 33)
        033E81519ECF373E:A3A5C7E1C051B71A
        898FB3438C9550E2:74D980F147EB4D06
        9D
        bitcoin address:   1JXc8zsSeAPwqfAzLbBnZxNTfetZexH2bW
    21: OP_Data21 (= decimal 33)
        027AA4A8DAFFF9B6:307899BB7762BF92
        C50ABDE14C363671:9FFC4D4FABF3DC6B
        0F
        bitcoin address:   1BDp6sR3bHH8ACzbwZccY4y9GohG3KX828
    53: OP_Data53 (= decimal 83)
    AE: OP_CHECKMULTISIG
</code></pre>

<p>So just an "old type" multisig transaction. </p>

CC BY-SA 3.0
2018-01-31T13:01:50.750Z
2018-01-31T13:01:50.750Z
pebwindkraft
<p>It seems that some transactions, although having "prev_out" field in their "inputs", does not have "addr" in the "prev_out", i.e. they do not have input address. What is this kind of transactions for?</p>

<p>e.g. transaction hash: 38d4154f800cbbce0ac39772dd88d338424be21ba36ccb6a11110a029e6b5a1e</p>

<transactions><address><transaction-input>
Unable to decode input address
Jerry Xue
# Unable to decode input address

(Asked by: username_0 on 2018-01-31)

It seems that some transactions, although having "prev\_out" field in their "inputs", does not have "addr" in the "prev\_out", i.e. they do not have input address. What is this kind of transactions for?

e.g. transaction hash: 38d4154f800cbbce0ac39772dd88d338424be21ba36ccb6a11110a029e6b5a1e

**Tags:** transactions, address, transaction-input


---

## 1 answers

### Answer by username_1 on 2018-01-31. Score: 1 | Accepted answer

Yes, this tx has only the signatures in the V\_IN part (unlocking script), no public keys directly behind it, or a redeemscript. The V\_OUT part (locking script) has a redeemscript for a 2-of-3 multisig. Usually one would expect a redeemscript hash in the pubkeyscript, but here it is the plain hex codes.
So it is an old type multisig (not using P2SH). The unlocking script is the two signatures, and locking script provides the required pubkeys.

So what would happen on the stack:

`<sig1>`

`<sig2>`

`<redeem script data>` ("2" pk1 pk2 pk3 "3" CHECK\_MULTISIG)

In a first step the unlocking script is executed, and if valid (results in a TRUE value, or no remaining operators remain on the stack), the tx would be marked as valid. It only pushes data (the signatures), so ok. Then the second step would clear the stack, and sigscript and pubkeyscript would be pushed and executed. As one can see, the three elements on the stack can be resolved to TRUE, and as such it is a simple multisig.
Decoding the pubkeys in the redeem script shows:

```
5221037BF122821AE522F67B7BC09387C2907607CDD66E6BD67BCB53F39D5346ADC74821033E81519ECF373EA3A5C7E1C051B71A898FB3438C9550E274D980F147EB4D069D21027AA4A8DAFFF9B6307899BB7762BF92C50ABDE14C3636719FFC4D4FABF3DC6B0F53AE

    52: OP_2
    21: OP_Data21 (= decimal 33)
        037BF122821AE522:F67B7BC09387C290
        7607CDD66E6BD67B:CB53F39D5346ADC7
        48
        bitcoin address:   18pvHhDLrGJpJ7SznnoxxFdwPnKCqjqVCj
    21: OP_Data21 (= decimal 33)
        033E81519ECF373E:A3A5C7E1C051B71A
        898FB3438C9550E2:74D980F147EB4D06
        9D
        bitcoin address:   1JXc8zsSeAPwqfAzLbBnZxNTfetZexH2bW
    21: OP_Data21 (= decimal 33)
        027AA4A8DAFFF9B6:307899BB7762BF92
        C50ABDE14C363671:9FFC4D4FABF3DC6B
        0F
        bitcoin address:   1BDp6sR3bHH8ACzbwZccY4y9GohG3KX828
    53: OP_Data53 (= decimal 83)
    AE: OP_CHECKMULTISIG

```

So just an "old type" multisig transaction.


---

