mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 13:26:08 +01:00
Code Issues Projects 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==
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.
@ -271,14 +274,14 @@ For the avoidance of unclarity, the parameters to be determined are:
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0;
Until BIP-119 reaches ACTIVE state and the
SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is set, the network should
execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS for policy and a NOP for
consensus.
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 (to deny entry to the mempool) for policy and must evaluate as
a NOP for consensus (during block validation).
In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
PayToBareDefaultCheckTemplateVerifyHash
with no scriptSig data shall be made standard to permit relaying. Future template types may be
standardized later as policy changes.
with no scriptSig data may (is recommended to) be made standard to permit relaying. Future template types may be
standardized later as policy changes at the preference of the implementor.
==Reference Implementation==
@ -589,12 +592,13 @@ reuse-unsafe.
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.
====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.
Many OP_NOP upgrades prefer to fail in such circumstances. In particular, for
CHECKTEMPLATEVERIFY, making an invalid argument a NOP permits future soft-forks to upgrade the
semantics or loosed restrictions around the value being previously pushed only.
If the argument length is not exactly 32, CHECKTEMPLATEVERIFY treats it as a NOP during
consensus validation. Implementations are recommended to fail in such circumstances during non-consensus
relaying and mempool validation. In particular, making an invalid-length argument a failure aids future
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
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
(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 reference 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. 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
require an upgrade in order to treat PayToBareDefaultCheckTemplateVerifyHash chains with a confirmed ancestor as