Standardness rules related to BIP 16 (P2SH)

Question

I can read in BIP0016 wiki the P2SH Specification

Transactions that redeem these pay-to-script outpoints are only considered standard if the serialized script - also referred to as the redeemScript - is, itself, one of the other standard transaction types.

The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows:

Validation fails if there are any operations other than "push data" operations in the scriptSig. Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. The rules for validating these outpoints when relaying transactions or considering them for inclusion in a new block are as follows:

Validation fails if there are any operations other than "push data" operations in the scriptSig. Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. ...

• OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.
• OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated.
• All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations.

But in Antonopoulos's book I can read

Prior to version 0.9.2 of the Bitcoin Core client, Pay-to-Script-Hash was limited to the standard types of bitcoin transaction scripts, by the isStandard() function. That means that the redeem script presented in the spending transaction could only be one of the standard types: P2PK, P2PKH, or multisig nature, excluding RETURN and P2SH itself. As of version 0.9.2 of the Bitcoin Core client, P2SH transactions can contain any valid script, making the P2SH standard much more flexible and allowing for experimenta‐ tion with many novel and complex types of transactions.

Now, I'm using 0.19.0 and I'm able to create custom script and rely it in my regtest enviroment. the question is: Can The BIP0016 is obsolete? And if it is, where I can see which BIP is became obsolete?

Answer 1

In general, changes to policy rules are not specified in BIPs. They're up to individual clients anyway.

BIP16 is not obsolete, though its description of the standardness rules in Bitcoin Core is outdated by now. However, its consensus rules (i.e., what is valid in a block, not what will be relayed as individual transactions) are unmodified since it activated in 2012 — anything else would be a hard fork.

As far as policy in Bitcoin Core goes, in version 0.10.0 (2014), relaxed standardness for P2SH spends, allowing any script using up to 15 signature checks. Several later changes to standardness were made (including every script-affected softfork (CLTV, CSV, Segwit) was accompanied with making corresponding spends standard), but none so fundamental.

Today (Bitcoin Core v0.19.0) standardness rules for P2SH spends include:

• Max scriptSig size is 1650 bytes including redeemScript (not enforced on testnet)
• Max 15 signature checks in the script (not enforced on testnet)
• No opcodes intended for future upgrades (NOP3-NOP10) [discourage upgradable nops rule]
• No non-DER encoded signatures, or hybrid public keys [strictenc rule]
• No signatures with s values in the upper half of the range [low-s rule]
• The additional argument popped by OP_CHECKMULTISIG(VERIFY) must be exactly the empty byte array (as pushed by OP_0) [nulldummy rule]
• All pushes must use the minimal size encoding (OP_i instead of direct pushes where available, no OP_PUSHDATAi when unnecessary), integers can't have unnecessary zero padding [minimaldata rule]
• Execution must end with exactly one non-zero element on the stack [cleanstack rule]
• Checksig operations that fail must be passed an empty signature [nullfail rule]
• OP_CODESEPARATOR cannot be used (not even in an unexecuted branch).
• Signatures that are verified cannot appear in the scriptPubKey (they must come from the scriptSig) [const scriptcode rule]
• At the transaction level: no tx version above 2, and the whole tx cannot be larger than 400000 weight units (100000 bytes if no segwit inputs are present).