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

1 Answer 1


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:



<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:


    52: OP_2
    21: OP_Data21 (= decimal 33)
        bitcoin address:   18pvHhDLrGJpJ7SznnoxxFdwPnKCqjqVCj
    21: OP_Data21 (= decimal 33)
        bitcoin address:   1JXc8zsSeAPwqfAzLbBnZxNTfetZexH2bW
    21: OP_Data21 (= decimal 33)
        bitcoin address:   1BDp6sR3bHH8ACzbwZccY4y9GohG3KX828
    53: OP_Data53 (= decimal 83)

So just an "old type" multisig transaction.

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.