From c788bd9d0827224ed630b8f5ad9989de1609356c Mon Sep 17 00:00:00 2001
From: Jeremy Rubin <j@rubin.io>
Date: Fri, 7 May 2021 10:55:37 -0700
Subject: Update BIP-119 Variable Names

---
 bip-0119.mediawiki | 48 +++++++++++++++++++++++++-----------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

(limited to 'bip-0119.mediawiki')

diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index 730ffb9..658764d 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -27,9 +27,9 @@ OP_CHECKTEMPLATEVERIFY does the following:
 
 * There is at least one element on the stack, fail otherwise
 * The element on the stack is 32 bytes long, NOP otherwise
-* The StandardTemplateHash of the transaction at the current input index is equal to the element on the stack, fail otherwise
+* The DefaultCheckTemplateVerifyHash of the transaction at the current input index is equal to the element on the stack, fail otherwise
 
-The StandardTemplateHash commits to the serialized version, locktime, scriptSigs hash (if any
+The DefaultCheckTemplateVerifyHash commits to the serialized version, locktime, scriptSigs hash (if any
 non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and
 currently executing input index.
 
@@ -139,13 +139,13 @@ specification for the semantics of OP_CHECKTEMPLATEVERIFY.
     case OP_CHECKTEMPLATEVERIFY:
     {
         // if flags not enabled; treat as a NOP4
-        if (!(flags & SCRIPT_VERIFY_STANDARD_TEMPLATE)) break;
+        if (!(flags & SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH)) break;
         if (stack.size() < 1)
             return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
         // If the argument was not 32 bytes, treat as OP_NOP4:
         switch (stack.back().size()) {
             case 32:
-                if (!checker.CheckStandardTemplateHash(stack.back())) {
+                if (!checker.CheckDefaultCheckTemplateVerifyHash(stack.back())) {
                     return set_error(serror, SCRIPT_ERR_TEMPLATE_MISMATCH);
                 }
                 break;
@@ -161,17 +161,17 @@ specification for the semantics of OP_CHECKTEMPLATEVERIFY.
 
 The hash is computed as follows:
 
-    uint256 GetStandardTemplateHash(const CTransaction& tx, uint32_t input_index) {
-        return GetStandardTemplateHash(tx, GetOutputsSHA256(tx), GetSequenceSHA256(tx), input_index);
+    uint256 GetDefaultCheckTemplateVerifyHash(const CTransaction& tx, uint32_t input_index) {
+        return GetDefaultCheckTemplateVerifyHash(tx, GetOutputsSHA256(tx), GetSequenceSHA256(tx), input_index);
     }
-    uint256 GetStandardTemplateHash(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
+    uint256 GetDefaultCheckTemplateVerifyHash(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
                                     const uint32_t input_index) {
         bool skip_scriptSigs = std::find_if(tx.vin.begin(), tx.vin.end(),
                 [](const CTxIn& c) { return c.scriptSig != CScript(); }) == tx.vin.end();
-        return skip_scriptSigs ? GetStandardTemplateHashEmptyScript(tx, outputs_hash, sequences_hash, input_index) :
-            GetStandardTemplateHashWithScript(tx, outputs_hash, sequences_hash, GetScriptSigsSHA256(tx), input_index);
+        return skip_scriptSigs ? GetDefaultCheckTemplateVerifyHashEmptyScript(tx, outputs_hash, sequences_hash, input_index) :
+            GetDefaultCheckTemplateVerifyHashWithScript(tx, outputs_hash, sequences_hash, GetScriptSigsSHA256(tx), input_index);
     }
-    uint256 GetStandardTemplateHashWithScript(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
+    uint256 GetDefaultCheckTemplateVerifyHashWithScript(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
                                     const uint256& scriptSig_hash, const uint32_t input_index) {
         auto h =  CHashWriter(SER_GETHASH, 0)
             << tx.nVersion
@@ -184,7 +184,7 @@ The hash is computed as follows:
             << input_index;
         return h.GetSHA256();
     }
-    uint256 GetStandardTemplateHashEmptyScript(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
+    uint256 GetDefaultCheckTemplateVerifyHashEmptyScript(const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
                                     const uint32_t input_index) {
         auto h =  CHashWriter(SER_GETHASH, 0)
             << tx.nVersion
@@ -198,9 +198,9 @@ The hash is computed as follows:
     }
 
 
-A PayToBasicStandardTemplate output matches the following template:
+A PayToBareDefaultCheckTemplateVerifyHash output matches the following template:
 
-    bool CScript::IsPayToBasicStandardTemplate() const
+    bool CScript::IsPayToBareDefaultCheckTemplateVerifyHash() const
     {
      // Extra-fast test for pay-to-basic-standard-template CScripts:
      return (this->size() == 34 &&
@@ -221,7 +221,8 @@ For the avoidance of unclarity, the parameters are:
     consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nStartTime = 1583020800; // March 1, 2020
     consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = 1614556800; //  March 1, 2021
 
-In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a PayToBasicStandardTemplate
+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.
 
@@ -241,7 +242,7 @@ Below we'll discuss the rules one-by-one:
 
 
 
-====The StandardTemplateHash of the transaction at the current input index matches the top of the stack====
+====The DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stack====
 
 The set of data committed to is a superset of data which can impact the TXID of the transaction,
 other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead
@@ -272,13 +273,13 @@ spend, as long as the exact scriptsig for the legacy output is committed. This i
 simply disallowing any scriptSig to be set with CHECKTEMPLATEVERIFY.
 
 If no scriptSigs are set in the transaction, there is no purpose in hashing the data or including it
-in the StandardTemplateHash, so we elide it. It is expected to be common that no scriptSigs will be
+in the DefaultCheckTemplateVerifyHash, so we elide it. It is expected to be common that no scriptSigs will be
 set as segwit mandates that the scriptSig must be empty (to avoid malleability).
 
 We commit to the hash rather than the values themselves as this is already
 precomputed for each transaction to optimize SIGHASH_ALL signatures.
 
-Committing to the hash additionally makes it simpler to construct StandardTemplateHashes safely and unambiguously from
+Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
 script.
 
 
@@ -314,7 +315,7 @@ specific applications.
 
 In principal, committing to the Sequences Hash (below) implicitly commits to the number of inputs,
 making this field strictly redundant. However, separately committing to this number makes it easier
-to construct StandardTemplateHashes from script.
+to construct DefaultCheckTemplateVerifyHash from script.
 
 We treat the number of inputs as a `uint32_t` because signature checking code expects nIn to be an
 `unsigned int`, even though in principal a transaction can encode more than a `uint32_t`'s worth of
@@ -329,14 +330,14 @@ with OP_CSV because OP_CSV enforces a minimum nSequence value, not a literal val
 We commit to the hash rather than the values themselves as this is already
 precomputed for each transaction to optimize SIGHASH_ALL signatures.
 
-Committing to the hash additionally makes it simpler to construct StandardTemplateHashes safely and unambiguously from
+Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
 script.
 
 =====Committing to the Number of Outputs=====
 
 In principal, committing to the Outputs Hash (below) implicitly commits to the number of outputs,
 making this field strictly redundant. However, separately committing to this number makes it easier
-to construct StandardTemplateHashes from script.
+to construct DefaultCheckTemplateVerifyHash from script.
 
 We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`, even
 though in principal a transaction could encode more outputs.
@@ -349,7 +350,7 @@ requested.
 We commit to the hash rather than the values themselves as this is already
 precomputed for each transaction to optimize SIGHASH_ALL signatures.
 
-Committing to the hash additionally makes it simpler to construct StandardTemplateHashes safely and unambiguously from
+Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
 script.
 
 =====Committing to the current input's index=====
@@ -370,7 +371,8 @@ added to Bitcoin, the index may simply be passed in by the witness before hashin
 
 =====Committing to Values by Hash=====
 
-Committing to values by hash makes it easier and more efficient to construct a StandardTemplateHash
+Committing to values by hash makes it easier and more efficient to construct a
+DefaultCheckTemplateVerifyHash
 from script. Fields which are not intended to be set may be committed to by hash without incurring
 O(n) overhead to re-hash.
 
@@ -528,7 +530,7 @@ for mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY a
 (see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.
 
 Older wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY outputs, but will
-require an upgrade in order to treat PayToBasicStandardTemplate chains with a confirmed ancestor as
+require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as
 being "trusted" (i.e., eligible for spending before the transaction is confirmed).
 
 Backports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation)
-- 
cgit v1.2.3

