mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-19 05:45:07 +01:00
Code Issues Projects Releases Wiki Activity

[BIP-119] Clarify that policy is not validity + what a covenant is.

Browse Source
This commit is contained in:
Jeremy Rubin 2022-01-26 01:44:39 -08:00 committed by GitHub
parent 02de475efc
commit 9eb17cd296
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
bip-0119.mediawiki
View File

@ -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