bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

Merge pull request #1278 from JeremyRubin/patch-6

Browse Source 
[BIP-119] Clarify that policy is not validity + what a covenant is.
This commit is contained in:
Luke Dashjr 2022-03-23 21:43:29 +00:00 committed by GitHub
commit 274fa400d6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 20 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
bip-0119.mediawiki
View File

@ -39,9 +39,12 @@ The recommended standardness rules additionally:
==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
valuable use cases without significant risk. valuable use cases without significant risk.
@ -271,14 +274,14 @@ For the avoidance of unclarity, the parameters to be determined are:
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0; consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0;
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==
@ -589,12 +592,13 @@ reuse-unsafe.
Because CHECKTEMPLATEVERIFY commits to the input index currently being spent, reused-keys are Because CHECKTEMPLATEVERIFY commits to the input index currently being spent, reused-keys are
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
stricter standardness rules to be enforced during consensus. Should that developer submit a stricter standardness rules to be enforced during consensus. Should that developer submit a
@ -710,8 +714,9 @@ for an OP_NOP are a soft fork, so existing software will be fully functional wit
for mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY for mining and block validation. Similar soft forks for OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY
(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
require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as