[BIP-119] Better Explain AnyPrevout v.s. CTV

1 files changed, 22 insertions, 11 deletions

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