Blockchain Security Report:
Standard and Non-Standard Transactions

About blockchain Security Report: Standard and Non-Standard Transactions

In blockchain scripts, there are standard and non-standard transactions. Both types are evaluated in the form of scriptSig, scriptPubKey, or a combination of scriptSig and scriptPubKey.

And on the mainnet, only standard transactions are accepted. Strictly speaking, only standard transactions are accepted into the memory pool. This means that once included in a block, there is a certain level of leniency, and if the non-standard transaction’s EvalScript returns true, the node will accept the block. The memory pool is an area where transactions wait to be included in a block through mining (or staking), and it is also shared via P2P.

When you receive coins, you first get a notification as an unconfirmed transaction, right? This is because the content of the memory pool, including the sent transaction, is synchronized via P2P. A third-party miner on any node aggregates this information and reports it to be included in a block, and only then is it included in a block.

Thus the memory pool is shared, if you were to mine (or stake) yourself, your transaction would be approved by yourself and thus be valid.

Regarding non-standard transactions

Regarding non-standard transactions, EvalScript must always return true initially. This is because if EvalScript does not return true, the transaction will not be accepted into the memory pool or elsewhere, regardless of its form.

The distinction between standard and non-standard transactions is determined by the shape of the scriptPubKey used to process each transaction. For example, there is P2PKH, right? First, the address and scriptPubKey are analyzed, and then the scriptSig required to unlock that script is determined. During this process, the distinction between standard and non-standard transactions is established.

However, this restriction has the drawback that a large portion of scripts cannot be utilized. This is because only predefined specifications such as P2PKH are accepted into the memory pool, meaning that other non-standard transactions will not be included in a block.

Nevertheless, if non-standard transactions are included in a block, each node must validate the non-standard scripts within the block during the block acceptance process. Therefore, if non-standard scripts are included in blocks without limitation, it can significantly increase the load during synchronization.

The transactions that can be incorporated as non-standard are almost non-existent, but there is one exception. That is OP_CHECKMULTISIG.

This opcode allows for a variable number of required keys, and it does not necessarily require all the specified keys. In other words, up to a 3-3 multisig treated as standard, it takes a variable-length structure, and for 1-3 and 2-3 multisig, the difference of two and one respectively can be handled freely. Since this free portion is not evaluated by EvalScript, there was a mechanism to incorporate new functionalities by embedding them in this part.