transactions – When the validity of scriptPubKey is checked?


I’ve a few questions associated to validation of script in transaction output (scriptPubKey).

Since all my confusion is said to the OP_RETURN opcode and OP_RETURN transaction, i.e. the next query and reply from Pieter Wuille all my questions are associated to the validation of the scriptPubKey that accommodates this operator (OP_RETURN transaction), however I assume the identical is true for all different output scripts.

Let’s start.

Primarily based on what the Bitcoin wiki says that OP_RETURN marks the transaction as invalid and per Pieter’s remark:

Transaction output scripts are solely executed on the time they’re
tried to be spent.

My first query is:

1. If the transaction output scripts are solely executed on the time they’re tried to spent, does it imply that in scriptPubKey (transaction output script) we will write no matter we would like and its validity shall be solely checked on the time of utilizing?

I believe the reply to first query is fake. The scriptPubKey is executed on the time its tried to spent however its validity is checked on the time of creation of transaction that has that script in its transaction output. It is like a compiling and executing C program. Compiling means checking for syntax and semantic errors, or in case of scriptPubKey test, for instance, if all right opcodes are used, if script dimension is right, if it is among the customary transaction (if any of the above isn’t glad, the transaction containing this UTXO shall be marked as invalid and discarded from the community). Then again, executing a C program also can trigger this system to develop into invalid, say when dividing by 0. And that is precisely as with scriptPubKey and it is executing (as Pieter mentioned) when trying to spend it. If on the time of execution the script is marked as invalid (say it stays FALSE on the stack or an OP_RETURN operator is encountered), then the transaction that consumes the UTXO (not the one accommodates this UTXO) is marked as invalid.

2. Is the above written true? Is the validity of the transaction output checked when making the transaction, after which whereas utilizing the UTXO if one thing within the output script causes invalidity, the transaction that consumes that output shall be marked as invalid?

Under is a query associated as to if I perceive validation accurately within the context of OP_RETURN.

When output containing [OP_RETURN] [DATA_PUSH] [data] is created, that UTXO shall be efficiently validated (since the whole lot in it’s OK) and acknowledged as customary OP_RETURN output that doesn’t develop into a part of the UTXO set. If the whole lot different in transaction is okay, transaction is legitimate. Nevertheless, if we have been to attempt to use this UTXO, the transaction that consumes the given output shall be marked as invalid. Then again, if we add one thing further in entrance of OP_RETURN (some random opcode), it is not going to cross validation since it is not acknowledged as an ordinary transaction, so a transaction that has this output could be invalidated

3. Did I perceive accurately, that’s, was the above written accurately?

4. Does the whole lot beforehand written about validation really apply to all different varieties of output (P2PK, P2PKH, P2WPKH, P2SH and so forth.). That’s, validating on creation after which doubtlessly marking an invalid transaction throughout execution (though with P2PKH this will solely occur by combining a locking and unlocking script the place the signature isn’t good, not like with an OP_RETURN transaction that UTXO itself marks an invalid transaction regardless to the unlock script)?

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Stay Connected

0FansLike
3,912FollowersFollow
0SubscribersSubscribe
- Advertisement -spot_img

Latest Articles