Bitcoin Forum
May 07, 2024, 05:46:35 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Transaction input scripts  (Read 513 times)
alikim (OP)
Member
**
Offline Offline

Activity: 80
Merit: 11


View Profile
July 09, 2017, 10:55:21 AM
 #1

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?
1715103995
Hero Member
*
Offline Offline

Posts: 1715103995

View Profile Personal Message (Offline)

Ignore
1715103995
Reply with quote  #2

1715103995
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715103995
Hero Member
*
Offline Offline

Posts: 1715103995

View Profile Personal Message (Offline)

Ignore
1715103995
Reply with quote  #2

1715103995
Report to moderator
1715103995
Hero Member
*
Offline Offline

Posts: 1715103995

View Profile Personal Message (Offline)

Ignore
1715103995
Reply with quote  #2

1715103995
Report to moderator
1715103995
Hero Member
*
Offline Offline

Posts: 1715103995

View Profile Personal Message (Offline)

Ignore
1715103995
Reply with quote  #2

1715103995
Report to moderator
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4653



View Profile
July 09, 2017, 03:23:51 PM
 #2

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.
alikim (OP)
Member
**
Offline Offline

Activity: 80
Merit: 11


View Profile
July 09, 2017, 04:13:32 PM
 #3

Thank you!
achow101
Moderator
Legendary
*
Offline Offline

Activity: 3388
Merit: 6631


Just writing some code


View Profile WWW
July 09, 2017, 06:19:14 PM
 #4

Yes, the input script can include OP codes.
It's important to note that only input scripts containing pushes are standard.

alikim (OP)
Member
**
Offline Offline

Activity: 80
Merit: 11


View Profile
July 09, 2017, 07:11:39 PM
 #5

Yes, the input script can include OP codes.
It's important to note that only input scripts containing pushes are standard.

So what happens if an input script contains other OP codes? Will they be ignored or will the script be invalid?
HI-TEC99
Legendary
*
Offline Offline

Activity: 2772
Merit: 2846



View Profile
July 09, 2017, 07:19:34 PM
 #6

Yes, the input script can include OP codes.
It's important to note that only input scripts containing pushes are standard.

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

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
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4653



View Profile
July 09, 2017, 08:13:44 PM
 #7

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

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

achow101
Moderator
Legendary
*
Offline Offline

Activity: 3388
Merit: 6631


Just writing some code


View Profile WWW
July 09, 2017, 08:55:40 PM
 #8

It's important to note that only input scripts containing pushes are standard.
Interesting.  How does P2SH work then?  Isn't it necessary to provide OP codes in the input?
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 <hash> 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.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!