diff options
| -rw-r--r-- | bip-0119.mediawiki | 33 |
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 |