2

I used the guide, how to make escrow from bitcoin console.

Here are my transactions in testnet: tx1 tx2

I am confused about ScriptPublicKey in tx1:

OP_HASH160 a7a62637430b44c922cbce4fc8bd53d11b7c4c25 OP_EQUAL

So it is just calculate Hash160 of top stack value, and compare it with a7a6...25. In the ScriptSig of tx2 we can see 4 values, which will be pushed to stack for validation. But vout script uses only the top stack value:

5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae

Other 2 values are signatures:

304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01

As we can see, this signatures are not validating by vout script.

And why this functionallity does not work with OP_CHECKMULTISIG?

1

Take a look at BIP0016.

This new transaction type is redeemed by a standard scriptSig:

...signatures... {serialized script}

And...

{serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.

In this case, {serialized script} is {m [pubkey1] [pubkey2] ... [pubkeyn] n OP_CHECKMULTISIG} for a m-of-n transaction. When Bitcoin detects one of these special transactions, the serialized script is popped of the stack as soon as its hash is validated (you're validating the script hash! not an actual public key!) and then executed with the remaining stack intact.

Your payment script looks like this:

0 /* null element because a bug pops one-too-many items */
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01 
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01 
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae

The last part (5221020678...52ae) is actually your serialized script. If you decode it you get:

2 020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f54 02bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f00 2 OP_CHECKMULTISIG

Which is a 2-of-2 transaction!

The first two parts not including the null element (the ones that look like 304...01) are just your provided signatures which are going to validate against the serialized public keys when OP_CHECKMULTISIG is executed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.