@@ -518,17 +518,28 @@ something similar to templates, via a scriptPubKey like:
518
518
519
519
<sig of desired TX with PK and fixed nonce R || SIGHASH_ANYPREVOUTANYSCRIPT <PK with public SK> OP_CHECKSIG
520
520
521
- SIGHASH_ANYPREVOUTANYSCRIPT bears additional technical and implementation risks that may preclude
522
- its viability for inclusion in Bitcoin, but the capabilities above are similar to what
523
- CHECKTEMPLATEVERIFY offers. However, CHECKTEMPLATEVERIFY has benefits in terms of verification
524
- speed, as it requires only hash computation rather than signature operations. This can be
525
- significant when constructing large payment trees or programmatic compilations. CHECKTEMPLATEVERIFY
526
- also has a feature-wise benefit in that it provides a robust pathway for future template upgrades.
527
-
528
- CHECKSIGFROMSTACK along with OP_CAT may also be used to emulate CHECKTEMPLATEVERIFY. However such
529
- constructions are more complicated to use than CHECKTEMPLATEVERIFY, and encumbers additional
530
- verification overhead absent from CHECKTEMPLATEVERIFY. These types of covenants also bear similar
531
- potential recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin.
521
+ SIGHASH_ANYPREVOUTANYSCRIPT bears additional technical and implementation risks
522
+ that may preclude its viability for inclusion in Bitcoin, but the capabilities
523
+ above are similar to what CHECKTEMPLATEVERIFY offers. The key functional
524
+ difference between SIGHASH_ANYPREVOUTANYSCRIPT and OP_CHECKTEMPLATEVERIFY is
525
+ that OP_CHECKTEMPLATEVERIFY restricts the number of additional inputs and
526
+ precludes dynamically determined change outputs while
527
+ SIGHASH_ANYPREVOUTANYSCRIPT can be combined with SIGHASH_SINGLE or
528
+ SIGHASH_ANYONECANPAY. For the additional inputs, OP_CHECKTEMPLATEVERIFY also
529
+ commits to the scriptsig and sequence, which allows for specifying specific P2SH
530
+ scripts (or segwit v0 P2SH) which have some use cases. Furthermore,
531
+ CHECKTEMPLATEVERIFY has benefits in terms of script size (depending on choice of
532
+ PK, SIGHASH_ANYPREVOUTANYSCRIPT may use about 2x-3x the bytes) and verification
533
+ speed, as OP_CHECKTEMPLATEVERIFY requires only hash computation rather than
534
+ signature operations. This can be significant when constructing large payment
535
+ trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise
536
+ benefit in that it provides a robust pathway for future template upgrades.
537
+
538
+ CHECKSIGFROMSTACK along with OP_CAT may also be used to emulate
539
+ CHECKTEMPLATEVERIFY. However such constructions are more complicated to use
540
+ than CHECKTEMPLATEVERIFY, and encumbers additional verification overhead absent
541
+ from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential
542
+ recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin.
532
543
533
544
534
545
Given the simplicity of this approach to implement and analyze, and the benefits realizable by user
0 commit comments