[BIP-119] Make it abundantly clear that policy and standard are recom…

…mendations.

bip-0119.mediawiki

@@ -274,14 +274,14 @@ For the avoidance of unclarity, the parameters to be determined are:
     consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0;
 
 Until BIP-119 reaches ACTIVE state and the 
-SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is set, the network should
-execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS for policy and a NOP for
-consensus.
+SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to)
+execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS (to deny entry to the mempool) for policy and must evaluate as
+a NOP for consensus (during block validation).
 
 In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
 PayToBareDefaultCheckTemplateVerifyHash
-with no scriptSig data shall be made standard to permit relaying. Future template types may be
-standardized later as policy changes.
+with no scriptSig data may (is recommended to) be made standard to permit relaying. Future template types may be
+standardized later as policy changes at the preference of the implementor.
 
 ==Reference Implementation==
 
@@ -592,12 +592,13 @@ reuse-unsafe.
 Because CHECKTEMPLATEVERIFY commits to the input index currently being spent, reused-keys are
 guaranteed to execute in separate transactions which reduces the risk of "half-spend" type issues.
 
-====NOP-Default and Standardness Rules====
+====NOP-Default and Recommended Standardness Rules====
 
-If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP.
-Many OP_NOP upgrades prefer to fail in such circumstances. In particular, for
-CHECKTEMPLATEVERIFY, making an invalid argument a NOP permits future soft-forks to upgrade the
-semantics or loosed restrictions around the value being previously pushed only.
+If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP during
+consensus validation. Implementations are recommended to fail in such circumstances during non-consensus
+relaying and mempool validation. In particular, making an invalid-length argument a failure aids future
+soft-forks upgrades to be able to rely on the tighter standard restrictions to safely loosen
+the restrictions for standardness while tightening them for consensus with the upgrade's rules.
 
 The standardness rules may lead an unscrupulous script developer to accidentally rely on the
 stricter standardness rules to be enforced during consensus. Should that developer submit a
@@ -713,8 +714,9 @@ for an OP_NOP are a soft fork, so existing software will be fully functional wit
 for mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY
 (see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.
 
-In contrast to previous forks, OP_CHECKTEMPLATEVERIFY's implementation does not allow transactions with spending
-scripts using it to be accepted to the mempool or relayed under standard policy until the new rule is active.
+In contrast to previous forks, OP_CHECKTEMPLATEVERIFY's reference implementation does not allow transactions with spending
+scripts using it to be accepted to the mempool or relayed under standard policy until the new rule is active. Other implementations
+are recommended to follow this rule as well, but not required.
 
 Older wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY outputs, but will
 require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as