Topic: Transaction input scripts (Read 545 times)

It's actually horribly hacky (and I didn't realize this until I read the code).

The redeemscript is actually a blob of data which is pushed to the stack first. Once the script (input and output script, no redeemscript) is interpreted once, the verifier checks if the scriptPubKey was a P2SH script (of the form OP_HASH160 OP_EQUAL). If it is, it pops the first item from the stack (which will be the redeemscript) and interprets that as a script and runs it. So the input script only consists of pushes since the redeemscript is really just a push of X bytes and is only later actually treated as a script.

Interesting.  How does P2SH work then?  Isn't it necessary to provide OP codes in the input?

Most pools will reject it because it's non-standard. One pool that will confirm non-standard transactions is eligius. You can probably still use this link to push a non-standard transaction. However, it's currently migrating its website so I'm not sure how long that link will work for, or if it still works.

http://eligius.st/~wizkid057/newstats/pushtxn.php

So what happens if an input script contains other OP codes? Will they be ignored or will the script be invalid?

It's important to note that only input scripts containing pushes are standard.

Thank you!

Yes, the input script can include OP codes.

However, your question seems to include a misunderstanding...

"or is it always treated as a data that will be automatically pushed on the stack"

The input script isn't "treated as a data". The way it works is that the input script and the output script are concatenated together (input script first followed by output script).  Then the resulting script is processed.

So, the reason that the pubkey and the signature are "pushed to the stack" with P2PKH scripts is because the input script includes instructions that push those values onto the stack.

Lets take a look at this transaction:
https://blockchain.info/tx/714db847a01bbcdf287708374c240ac31b751a4f5df5f9a6873bd1c95452b26a

Here's the hex:
https://blockchain.info/rawtx/714db847a01bbcdf287708374c240ac31b751a4f5df5f9a6873bd1c95452b26a?format=hex

I'll add some line breaks after each component and label those components to make it easier to follow along:

Taking a look at that Txout-script, you'll see the six components you expect:

76_a9_14_85a80598ccff62cb567a8c276f4c7b7e1b562009_88_ac


Now lets take a look at the Txin-script.  It contains 4 components:

48_3045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd02 2023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301_21_0211de1 58e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb


The "PUSH 72 BYTES" and "PUSH 33 BYTES" in the Txin-script are the reason that the SIG and PUBKEY end up on the stack.

Can a script that is used in a transaction input contain OP codes or is it always treated as a data that will be automatically pushed on the stack before applying the output script from the UTXO mentioned in this input?