diff options
| author | Jeremy Rubin <j@rubin.io> | 2022-01-26 01:44:39 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-01-26 01:44:39 -0800 |
| commit | 9eb17cd2964e7c48dc2cb0b3eef5fdc627eeeca8 (patch) | |
| tree | 96582bb620b12f68d6877c2f3144b5b3cf6066be /bip-0119.mediawiki | |
| parent | 02de475efc528058bd04a0c4ad31b6422aed5f5f (diff) | |
[BIP-119] Clarify that policy is not validity + what a covenant is.
Diffstat (limited to 'bip-0119.mediawiki')
| -rw-r--r-- | bip-0119.mediawiki | 13 |
1 files changed, 8 insertions, 5 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 29f6271..d456aea 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -39,9 +39,12 @@ The recommended standardness rules additionally: ==Motivation== -Covenants are restrictions on how a coin may be spent beyond key ownership. 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. +Covenants are restrictions on how a coin may be spent beyond key ownership. This is a general +definition based on the legal definition which even simple scripts using CSV would satisfy. +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 valuable use cases without significant risk. @@ -710,8 +713,8 @@ 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 (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 -valid for policy until the new rule is active. +In contrast to previous forks, OP_CHECKTEMPLATEVERIFY's implementation does not allow transactions with spending +scripts using it to be accepted to the mempool or relayed under standard policy until the new rule is active. 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 |