BIP 0119 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/758a58ab54fddce0/bip-0119.mediawiki

2024-05-29T04:47:58Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/758a58ab54fddce0/bip-0119.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/f450bee7a4efeff2/bip-0119.mediawiki

2024-04-23T18:43:10Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/f450bee7a4efeff2/bip-0119.mediawiki

← Older revision		Revision as of 18:43, 23 April 2024
Line 93:		Line 93:

	# If the hashes do not match, return error		# If the hashes do not match, return error
	if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data)		if stack[-1] != self.context.tx.get_default_check_template_hash(self.context.nIn, self.context.precomputed_ctv_data):
	return self.errors_with(errors.script_err_template_mismatch)		return self.errors_with(errors.script_err_template_mismatch)

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/fa21bdec664d6d25/bip-0119.mediawiki

2023-08-16T15:11:03Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/fa21bdec664d6d25/bip-0119.mediawiki

← Older revision		Revision as of 15:11, 16 August 2023
Line 7:		Line 7:
	Title: CHECKTEMPLATEVERIFY		Title: CHECKTEMPLATEVERIFY
	Author: Jeremy Rubin <j@rubin.io>		Author: Jeremy Rubin <j@rubin.io>
			James O'Beirne <vaults@au92.org>
	Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119		Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0119
	Status: Draft		Status: Draft

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8b41d49d3389d08a/bip-0119.mediawiki

2023-06-30T06:13:58Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8b41d49d3389d08a/bip-0119.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/43da5dec5eaf0d81/bip-0119.mediawiki

2022-08-04T11:54:21Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/43da5dec5eaf0d81/bip-0119.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/01c07e8c5b6cd52b/bip-0119.mediawiki

2022-05-05T16:58:15Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/01c07e8c5b6cd52b/bip-0119.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/274fa400d630ba75/bip-0119.mediawiki

2022-03-23T22:09:06Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/274fa400d630ba75/bip-0119.mediawiki

← Older revision		Revision as of 22:09, 23 March 2022
Line 43:		Line 43:
	==Motivation==		==Motivation==

	Covenants are restrictions on how a coin may be spent beyond key ownership. Covenants can be useful		Covenants are restrictions on how a coin may be spent beyond key ownership. This is a general
	to construct smart contracts. As covenants are complex to implement and risk of introducing		definition based on the legal definition which even simple scripts using CSV would satisfy.
	fungibility discriminants they have not been seriously considered for inclusion in Bitcoin.		Covenants in Bitcoin transactions usually refer to restrictions on where coins can be transferred.
			Covenants can be useful to construct smart contracts. As covenants are complex to implement
			and risk of introducing fungibility discriminants they have not been seriously considered for
			inclusion in Bitcoin.

	This BIP introduces a simple covenant called a template which enables a limited set of highly		This BIP introduces a simple covenant called a template which enables a limited set of highly
Line 275:		Line 278:

	Until BIP-119 reaches ACTIVE state and the		Until BIP-119 reaches ACTIVE state and the
	SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is ~~set~~, ~~the network~~ should		SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to)
	execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS for policy and a NOP for		execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS (to deny entry to the mempool) for policy and must evaluate as
	consensus.		a NOP for consensus (during block validation).

	In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a		In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
	PayToBareDefaultCheckTemplateVerifyHash		PayToBareDefaultCheckTemplateVerifyHash
	with no scriptSig data ~~shall~~ be made standard to permit relaying. Future template types may be		with no scriptSig data may (is recommended to) be made standard to permit relaying. Future template types may be
	standardized later as policy changes.		standardized later as policy changes at the preference of the implementor.

	==Reference Implementation==		==Reference Implementation==
Line 593:		Line 596:
	guaranteed to execute in separate transactions which reduces the risk of "half-spend" type issues.		guaranteed to execute in separate transactions which reduces the risk of "half-spend" type issues.

	====NOP-Default and Standardness Rules====		====NOP-Default and Recommended Standardness Rules====

	If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP.		If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP during
	~~Many OP_NOP upgrades prefer~~ to fail in such circumstances. In particular~~, for~~		consensus validation. Implementations are recommended to fail in such circumstances during non-consensus
	~~CHECKTEMPLATEVERIFY~~, making an invalid argument a ~~NOP permits~~ future soft-forks to ~~upgrade~~ the		relaying and mempool validation. In particular, making an invalid-length argument a failure aids future
	~~semantics or loosed~~ restrictions ~~around~~ the ~~value being previously pushed only~~.		soft-forks upgrades to be able to rely on the tighter standard restrictions to safely loosen
			the restrictions for standardness while tightening them for consensus with the upgrade's rules.

	The standardness rules may lead an unscrupulous script developer to accidentally rely on the		The standardness rules may lead an unscrupulous script developer to accidentally rely on the
Line 714:		Line 718:
	(see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.		(see BIP-0065 and BIP-0112) have similarly changed OP_NOP semantics without introducing compatibility issues.

	In contrast to previous forks, OP_CHECKTEMPLATEVERIFY ~~will~~ not ~~make~~ scripts		In contrast to previous forks, OP_CHECKTEMPLATEVERIFY's reference implementation does not allow transactions with spending
	~~valid for~~ policy until the new rule is active.		scripts using it to be accepted to the mempool or relayed under standard policy until the new rule is active. Other implementations
			are recommended to follow this rule as well, but not required.

	Older wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY outputs, but will		Older wallet software will be able to accept spends from OP_CHECKTEMPLATEVERIFY outputs, but will

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8530c16c3bb12a46/bip-0119.mediawiki

2022-01-16T00:41:07Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/8530c16c3bb12a46/bip-0119.mediawiki

Show changes

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/4c6389f8431f6778/bip-0119.mediawiki

2021-12-26T13:31:12Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/4c6389f8431f6778/bip-0119.mediawiki

← Older revision		Revision as of 13:31, 26 December 2021
Line 170:		Line 170:
	}		}
	break;		break;

			Where

			bool CheckDefaultCheckTemplateVerifyHash(const std::vector<unsigned char>& hash) {
			return GetDefaultCheckTemplateVerifyHash(current_tx, current_input_index) == uint256(hash);
			}

	The hash is computed as follows:		The hash is computed as follows:

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0119.mediawiki

2021-12-15T16:00:53Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0119.mediawiki

Show changes

← Older revision		Revision as of 04:47, 29 May 2024
Line 197:		Line 197:
	configured to match Speedy Trial, as that is the current activation mechanism		configured to match Speedy Trial, as that is the current activation mechanism
	implemented in Bitcoin Core. Should another method become favored by the wider		implemented in Bitcoin Core. Should another method become favored by the wider
	Bitcoin ~~comminity~~, that might be used instead.		Bitcoin community, that might be used instead.

	The start time and bit in the implementation are currently set to bit 5 and		The start time and bit in the implementation are currently set to bit 5 and
Line 318:		Line 318:
	friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that		friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that
	the max inputs in a block is further restricted by the block size to around 25,000, which would fit		the max inputs in a block is further restricted by the block size to around 25,000, which would fit
	into a `uint16_t`, but that is an ~~uneccessary~~ abstraction leak.		into a `uint16_t`, but that is an unnecessary abstraction leak.

	=====Committing to the Sequences Hash=====		=====Committing to the Sequences Hash=====
Line 366:		Line 366:

	Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can		Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can
	be spent at multiple ~~indicies~~. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped		be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
	in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are		in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are
	added to Bitcoin, the index may simply be passed in by the witness before hashing.		added to Bitcoin, the index may simply be passed in by the witness before hashing.
Line 480:		Line 480:
	<H> CTV CTV CTV... CTV		<H> CTV CTV CTV... CTV

	Such a script would cause the ~~intepreter~~ to compute hashes (supposing N CTV's) over O(N*T) data.		Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data.
	If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N)		If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N)
	times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations		times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations
Line 620:		Line 620:
	An opcode which verifies the exact amount that is being spent in the		An opcode which verifies the exact amount that is being spent in the
	transaction, the amount paid as fees, or made available in a given output could		transaction, the amount paid as fees, or made available in a given output could
	be used to make safer OP_CHECKTEMPLATEVERIFY ~~addressses~~. For instance, if the		be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the
	OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1		OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1
	satoshis would result in a frozen UTXO and sending S+n satoshis would result in		satoshis would result in a frozen UTXO and sending S+n satoshis would result in

← Older revision		Revision as of 06:13, 30 June 2023
Line 65:		Line 65:

	The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described		The below code is the main logic for verifying CHECKTEMPLATEVERIFY, described
	in pythonic ~~pseduocode~~. The canonical specification for the semantics of		in pythonic pseudocode. The canonical specification for the semantics of
	OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can		OP_CHECKTEMPLATEVERIFY as implemented in C++ in the context of Bitcoin Core can
	be seen in the reference implementation.		be seen in the reference implementation.
Line 229:		Line 229:

	Test vectors are available in [/bip-0119/vectors the bip-0119/vectors		Test vectors are available in [/bip-0119/vectors the bip-0119/vectors
	directory] for checking compatibility with the ~~refrence~~ implementation and BIP.		directory] for checking compatibility with the reference implementation and BIP.

	==Rationale==		==Rationale==

	The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the		The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the
	future, as we become aware of more complex but shown to be safe use cases new template types can be added.		future, as we become aware of more complex but shown to be safe use cases, new template types can be added.

	Below we'll discuss the rules one-by-one:		Below we'll discuss the rules one-by-one:
Line 254:		Line 254:

	Committing these values, rather than restricting them to specific values, is		Committing these values, rather than restricting them to specific values, is
	more flexible as it permits users of CHECKTEMPLATEVERIFY ~~the~~ set the version and		more flexible as it permits users of CHECKTEMPLATEVERIFY to set the version and
	locktime as they please.		locktime as they please.

Line 262:		Line 262:
	segwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible		segwit transaction in which case it must be only the exact redeemscript. P2SH is incompatible
	(unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit		(unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit
	to the ScriptSig, which must contain the redeemscript, which is a hash cycle.		to the ScriptSig, which must contain the redeemscript, which is a hash cycle.

	To prevent malleability when not using a segwit input, we also commit to the		To prevent malleability when not using a segwit input, we also commit to the