@@ -27,9 +27,9 @@ OP_CHECKTEMPLATEVERIFY does the following:
27
27
28
28
* There is at least one element on the stack, fail otherwise
29
29
* The element on the stack is 32 bytes long, NOP otherwise
30
- * The StandardTemplateHash of the transaction at the current input index is equal to the element on the stack, fail otherwise
30
+ * The DefaultCheckTemplateVerifyHash of the transaction at the current input index is equal to the element on the stack, fail otherwise
31
31
32
- The StandardTemplateHash commits to the serialized version, locktime, scriptSigs hash (if any
32
+ The DefaultCheckTemplateVerifyHash commits to the serialized version, locktime, scriptSigs hash (if any
33
33
non-null scriptSigs), number of inputs, sequences hash, number of outputs, outputs hash, and
34
34
currently executing input index.
35
35
@@ -139,13 +139,13 @@ specification for the semantics of OP_CHECKTEMPLATEVERIFY.
139
139
case OP_CHECKTEMPLATEVERIFY:
140
140
{
141
141
// if flags not enabled; treat as a NOP4
142
- if (!(flags & SCRIPT_VERIFY_STANDARD_TEMPLATE )) break;
142
+ if (!(flags & SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH )) break;
143
143
if (stack.size() < 1)
144
144
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
145
145
// If the argument was not 32 bytes, treat as OP_NOP4:
146
146
switch (stack.back().size()) {
147
147
case 32:
148
- if (!checker.CheckStandardTemplateHash (stack.back())) {
148
+ if (!checker.CheckDefaultCheckTemplateVerifyHash (stack.back())) {
149
149
return set_error(serror, SCRIPT_ERR_TEMPLATE_MISMATCH);
150
150
}
151
151
break;
@@ -161,17 +161,17 @@ specification for the semantics of OP_CHECKTEMPLATEVERIFY.
161
161
162
162
The hash is computed as follows:
163
163
164
- uint256 GetStandardTemplateHash (const CTransaction& tx, uint32_t input_index) {
165
- return GetStandardTemplateHash (tx, GetOutputsSHA256(tx), GetSequenceSHA256(tx), input_index);
164
+ uint256 GetDefaultCheckTemplateVerifyHash (const CTransaction& tx, uint32_t input_index) {
165
+ return GetDefaultCheckTemplateVerifyHash (tx, GetOutputsSHA256(tx), GetSequenceSHA256(tx), input_index);
166
166
}
167
- uint256 GetStandardTemplateHash (const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
167
+ uint256 GetDefaultCheckTemplateVerifyHash (const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
168
168
const uint32_t input_index) {
169
169
bool skip_scriptSigs = std::find_if(tx.vin.begin(), tx.vin.end(),
170
170
[](const CTxIn& c) { return c.scriptSig != CScript(); }) == tx.vin.end();
171
- return skip_scriptSigs ? GetStandardTemplateHashEmptyScript (tx, outputs_hash, sequences_hash, input_index) :
172
- GetStandardTemplateHashWithScript (tx, outputs_hash, sequences_hash, GetScriptSigsSHA256(tx), input_index);
171
+ return skip_scriptSigs ? GetDefaultCheckTemplateVerifyHashEmptyScript (tx, outputs_hash, sequences_hash, input_index) :
172
+ GetDefaultCheckTemplateVerifyHashWithScript (tx, outputs_hash, sequences_hash, GetScriptSigsSHA256(tx), input_index);
173
173
}
174
- uint256 GetStandardTemplateHashWithScript (const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
174
+ uint256 GetDefaultCheckTemplateVerifyHashWithScript (const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
175
175
const uint256& scriptSig_hash, const uint32_t input_index) {
176
176
auto h = CHashWriter(SER_GETHASH, 0)
177
177
<< tx.nVersion
@@ -184,7 +184,7 @@ The hash is computed as follows:
184
184
<< input_index;
185
185
return h.GetSHA256();
186
186
}
187
- uint256 GetStandardTemplateHashEmptyScript (const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
187
+ uint256 GetDefaultCheckTemplateVerifyHashEmptyScript (const CTransaction& tx, const uint256& outputs_hash, const uint256& sequences_hash,
188
188
const uint32_t input_index) {
189
189
auto h = CHashWriter(SER_GETHASH, 0)
190
190
<< tx.nVersion
@@ -198,9 +198,9 @@ The hash is computed as follows:
198
198
}
199
199
200
200
201
- A PayToBasicStandardTemplate output matches the following template:
201
+ A PayToBareDefaultCheckTemplateVerifyHash output matches the following template:
202
202
203
- bool CScript::IsPayToBasicStandardTemplate () const
203
+ bool CScript::IsPayToBareDefaultCheckTemplateVerifyHash () const
204
204
{
205
205
// Extra-fast test for pay-to-basic-standard-template CScripts:
206
206
return (this->size() == 34 &&
@@ -221,7 +221,8 @@ For the avoidance of unclarity, the parameters are:
221
221
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nStartTime = 1583020800; // March 1, 2020
222
222
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = 1614556800; // March 1, 2021
223
223
224
- In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a PayToBasicStandardTemplate
224
+ In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
225
+ PayToBareDefaultCheckTemplateVerifyHash
225
226
with no scriptSig data shall be made standard to permit relaying. Future template types may be
226
227
standardized later as policy changes.
227
228
@@ -241,7 +242,7 @@ Below we'll discuss the rules one-by-one:
241
242
242
243
243
244
244
- ====The StandardTemplateHash of the transaction at the current input index matches the top of the stack ====
245
+ ====The DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stack ====
245
246
246
247
The set of data committed to is a superset of data which can impact the TXID of the transaction,
247
248
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
272
273
simply disallowing any scriptSig to be set with CHECKTEMPLATEVERIFY.
273
274
274
275
If no scriptSigs are set in the transaction, there is no purpose in hashing the data or including it
275
- in the StandardTemplateHash , so we elide it. It is expected to be common that no scriptSigs will be
276
+ in the DefaultCheckTemplateVerifyHash , so we elide it. It is expected to be common that no scriptSigs will be
276
277
set as segwit mandates that the scriptSig must be empty (to avoid malleability).
277
278
278
279
We commit to the hash rather than the values themselves as this is already
279
280
precomputed for each transaction to optimize SIGHASH_ALL signatures.
280
281
281
- Committing to the hash additionally makes it simpler to construct StandardTemplateHashes safely and unambiguously from
282
+ Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
282
283
script.
283
284
284
285
@@ -314,7 +315,7 @@ specific applications.
314
315
315
316
In principal, committing to the Sequences Hash (below) implicitly commits to the number of inputs,
316
317
making this field strictly redundant. However, separately committing to this number makes it easier
317
- to construct StandardTemplateHashes from script.
318
+ to construct DefaultCheckTemplateVerifyHash from script.
318
319
319
320
We treat the number of inputs as a `uint32_t` because signature checking code expects nIn to be an
320
321
`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
329
330
We commit to the hash rather than the values themselves as this is already
330
331
precomputed for each transaction to optimize SIGHASH_ALL signatures.
331
332
332
- Committing to the hash additionally makes it simpler to construct StandardTemplateHashes safely and unambiguously from
333
+ Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
333
334
script.
334
335
335
336
=====Committing to the Number of Outputs =====
336
337
337
338
In principal, committing to the Outputs Hash (below) implicitly commits to the number of outputs,
338
339
making this field strictly redundant. However, separately committing to this number makes it easier
339
- to construct StandardTemplateHashes from script.
340
+ to construct DefaultCheckTemplateVerifyHash from script.
340
341
341
342
We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`, even
342
343
though in principal a transaction could encode more outputs.
@@ -349,7 +350,7 @@ requested.
349
350
We commit to the hash rather than the values themselves as this is already
350
351
precomputed for each transaction to optimize SIGHASH_ALL signatures.
351
352
352
- Committing to the hash additionally makes it simpler to construct StandardTemplateHashes safely and unambiguously from
353
+ Committing to the hash additionally makes it simpler to construct DefaultCheckTemplateVerifyHash safely and unambiguously from
353
354
script.
354
355
355
356
=====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
370
371
371
372
=====Committing to Values by Hash =====
372
373
373
- Committing to values by hash makes it easier and more efficient to construct a StandardTemplateHash
374
+ Committing to values by hash makes it easier and more efficient to construct a
375
+ DefaultCheckTemplateVerifyHash
374
376
from script. Fields which are not intended to be set may be committed to by hash without incurring
375
377
O(n) overhead to re-hash.
376
378
@@ -528,7 +530,7 @@ for mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY a
528
530
(see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.
529
531
530
532
Older wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY outputs, but will
531
- require an upgrade in order to treat PayToBasicStandardTemplate chains with a confirmed ancestor as
533
+ require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as
532
534
being "trusted" (i.e., eligible for spending before the transaction is confirmed).
533
535
534
536
Backports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation)
0 commit comments