mirror of
				https://github.com/bitcoin/bips.git
				synced 2025-10-27 14:09:10 +00:00 
			
		
		
		
	[BIP-119] Better Explain AnyPrevout v.s. CTV
This commit is contained in:
		
							parent
							
								
									8364e25ebc
								
							
						
					
					
						commit
						27466fa815
					
				| @ -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. | ||||
| 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. | ||||
| 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 | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user