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

<p>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.</p>

<p>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.</p>

<p>Today (Bitcoin Core v0.19.0) standardness rules for P2SH spends include:</p>

<ul>
<li>Max scriptSig size is 1650 bytes including redeemScript (not enforced on testnet)</li>
<li>Max 15 signature checks in the script (not enforced on testnet)</li>
<li>No opcodes intended for future upgrades (NOP3-NOP10) [discourage upgradable nops rule]</li>
<li>No non-DER encoded signatures, or hybrid public keys [strictenc rule]</li>
<li>No signatures with s values in the upper half of the range [low-s rule]</li>
<li>The additional argument popped by OP_CHECKMULTISIG(VERIFY) must be exactly the empty byte array (as pushed by OP_0) [nulldummy rule]</li>
<li>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]</li>
<li>Execution must end with exactly one non-zero element on the stack [cleanstack rule]</li>
<li>Checksig operations that fail must be passed an empty signature [nullfail rule]</li>
<li>OP_CODESEPARATOR cannot be used (not even in an unexecuted branch).</li>
<li>Signatures that are verified cannot appear in the scriptPubKey (they must come from the scriptSig) [const scriptcode rule]</li>
<li>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).</li>
</ul>

CC BY-SA 4.0
2020-03-16T08:14:00.560Z
Thanks so much. According to MCCCS's answer, I can't replicate the rules on regtest and testnet? I don't Use `acceptnonstdtxn`in my conf.
monkeyUser
CC BY-SA 4.0
2020-03-16T08:15:26.133Z
Regtest is identical to mainnet for everything listed here. Testnet is slightly different (it doesn't have the max scriptsig size or max 15 signature check rule, but all other listed rules still apply).
Pieter Wuille
CC BY-SA 4.0
2020-03-16T08:17:31.990Z
thanks again for your time! In general, regtest is close to mainnet, testnet is slightly different
monkeyUser
CC BY-SA 4.0
2020-03-16T08:20:24.343Z
Sorry I updated my comment, can you check if u can?
monkeyUser
CC BY-SA 4.0
2020-03-16T17:05:35.760Z
Yes, seems correct.
Pieter Wuille
CC BY-SA 4.0
2020-03-15T17:49:01.180Z
2020-03-16T17:08:46.460Z
2020-03-16T17:08:46.460Z
Pieter Wuille
<p>I can read in <a href="https://en.bitcoin.it/wiki/BIP_0016" rel="nofollow noreferrer">BIP0016 wiki</a> the P2SH Specification</p>

<blockquote>
  <p>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.</p>
  
  <p>The rules for validating these outpoints when relaying transactions or
  considering them for inclusion in a new block are as follows:</p>
  
  <p>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:</p>
  
  <p>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.
  ...</p>
</blockquote>

<ul>
<li>OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.</li>
<li>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.</li>
<li>All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations.</li>
</ul>

<p>But in Antonopoulos's book I can read</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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?</p>

<transactions><script><p2sh>
Standardness rules related to BIP 16 (P2SH)
monkeyUser
# Standardness rules related to BIP 16 (P2SH)

(Asked by: username_0 on 2020-03-14)

I can read in [BIP0016 wiki](https://en.bitcoin.it/wiki/BIP_0016) 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?

**Tags:** transactions, script, p2sh


---

## 1 answers

### Answer by username_1 on 2020-03-15. Score: 4 | Accepted answer

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).

> **Comments:**
> **username_0**: Thanks so much. According to MCCCS's answer, I can't replicate the rules on regtest and testnet? I don't Use `acceptnonstdtxn`in my conf.  
> **username_1**: Regtest is identical to mainnet for everything listed here. Testnet is slightly different (it doesn't have the max scriptsig size or max 15 signature check rule, but all other listed rules still apply).  
> **username_0**: thanks again for your time! In general, regtest is close to mainnet, testnet is slightly different  
> **username_0**: Sorry I updated my comment, can you check if u can?  
> **username_1**: Yes, seems correct.  

---

