@@ -225,9 +225,9 @@ In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a PayToBasi
225
225
with no scriptSig data shall be made standard to permit relaying. Future template types may be
226
226
standardized later as policy changes.
227
227
228
- ==Implementations ==
228
+ ==Reference Implementation ==
229
229
230
- An example implementation and tests are available here:
230
+ A reference implementation and tests are available here:
231
231
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify.
232
232
233
233
@@ -519,6 +519,20 @@ Given the simplicity of this approach to implement and analyze, and the benefits
519
519
applications, CHECKTEMPLATEVERIFY's template based approach is proposed in lieu of more complete
520
520
covenants system.
521
521
522
+ == Backwards Compatibility ==
523
+
524
+ OP_CHECKTEMPLATEVERIFY replaces a OP_NOP4 with stricter verification semantics. Therefore, scripts
525
+ which previously were valid will cease to be valid with this change. Stricter verification semantics
526
+ for an OP_NOP are a soft fork, so existing software will be fully functional without upgrade except
527
+ for mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY
528
+ (see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.
529
+
530
+ 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
532
+ being "trusted" (i.e., eligible for spending before the transaction is confirmed).
533
+
534
+ Backports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation)
535
+ for older node versions that can be patched but not upgraded to a newer major release.
522
536
523
537
524
538
== References ==
0 commit comments