Re: Transaction input scripts

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

Code:

0100000001ddc098ecd8865c66bbb114b84b167e08d5b14f0ad276c91ad6b822b8272cfb67100000006b483045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd022023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301210211de158e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fbffffffff01a1cc1300000000001976a91485a80598ccff62cb567a8c276f4c7b7e1b56200988ac00000000

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

Code:

Version: 01000000
   In-counter: 01
   Previous Tx hash: ddc098ecd8865c66bbb114b84b167e08d5b14f0ad276c91ad6b822b8272cfb67
Previous Txout-index: 10000000
  Txin-script length: 6b
Txin-script: 483045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd022023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301210211de158e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb
   sequence_number: ffffffff
   Out-counter: 01
   Value: a1cc130000000000
Txout-script length: 19
   Txout-script: 76a91485a80598ccff62cb567a8c276f4c7b7e1b56200988ac
   Locktime: 00000000

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

76_a9_14_85a80598ccff62cb567a8c276f4c7b7e1b562009_88_ac

Code:

OP_DUP: 76
   OP_HASH160: a9
   PUSH 20 BYTES: 14
20 BYTES OF DATA: 85a80598ccff62cb567a8c276f4c7b7e1b562009
  OP_EQUALVERIFY: 88
   OP_CHECKSIG: ac

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

48_3045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd02 2023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301_21_0211de1 58e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb

Code:

PUSH 72 BYTES: 48
72 BYTES of SIG DATA: 3045022100d70a6dd6fb9e5937a3583ae6bd544b4572a6ff75e98a06f91b23b197e9ab12dd022023ba2b2992bce0e84abcafee3bd5a8c0b51b45b2e5ec1fa803b9d42cd0c6e28301
PUSH 33 BYTES: 21
33 BYTES OF COMPRESSED PUBKEY DATA: 0211de158e14a99bbe29606660a9e9f068911e157a8c3324347fc6e77910fb83fb

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.