Home Bitcoin transactions – When the validity of scriptPubKey is checked?

transactions – When the validity of scriptPubKey is checked?

transactions – When the validity of scriptPubKey is checked?


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

I apologize for a little bit extra textual content, however I attempted to clarify intimately what I do not perceive.

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 incorporates 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 are able to write no matter we would like and its validity shall be solely checked on the time of utilizing? I imply if OP_RETURN makes the transaction invalid, and the validation is realized when creating the scriptPubKey (output), then the script with the given code can by no means be a part of the blockchain

I feel 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 examine, for instance, if all appropriate opcodes are used, if script measurement is appropriate, if it is likely one of the normal transaction (if any of the above is just not happy, the transaction containing this UTXO shall be marked as invalid and discarded from the community). Then again, executing a C program may also trigger this system to turn into invalid, say when dividing by 0. And that is precisely as with scriptPubKey and it is executing (as Pieter mentioned) when making an attempt 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 incorporates this UTXO) is marked as invalid. Subsequently, though validation is carried out when making a transaction output, OP_RETURN is a legitimate code that passes validation, however executing a script that incorporates it invalidates the transaction. Since scriptPubKey is simply executed when it’s consumed, that transaction shall be marked as invalid, and never the one which created scriptPubKey.

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 whether 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 normal OP_RETURN output that doesn’t turn into a part of the UTXO set. If the whole lot different in transaction is okay, transaction is legitimate. Nonetheless, if we have been to attempt to use this UTXO, the transaction that consumes the given output shall be marked as invalid, as a result of it incorporates OP_RETURN. Then again, if we add one thing further in entrance of OP_RETURN (some random opcode) in scriptPubKey, it is not going to move validation since it isn’t acknowledged as an ordinary transaction, so a transaction that has this output can be invalidated

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

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



Please enter your comment!
Please enter your name here