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] No double space after period, no trailing whitespaces

Browse Source
This commit is contained in:
Jeremy Rubin 2022-05-23 09:28:01 -07:00
parent de0ff362fc
commit b29a3d27bf
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
bip-0119.mediawiki
View File

@ -41,8 +41,8 @@ The recommended standardness rules additionally:
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
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.
@ -51,7 +51,7 @@ This BIP introduces a simple covenant called a *template* which enables a
limited set of highly valuable use cases without significant risk. BIP-119
templates allow for non-recursive fully-enumerated covenants with no dynamic
state. CTV serves as a replacement for a pre-signed transaction oracle, which
eliminates the trust and interactivity requirements. Examples of uses include
eliminates the trust and interactivity requirements. Examples of uses include
wallet vaults, non-interactive payment channel creation, congestion controlled
batching, efficient to construct discreet log contracts, and payment pools,
among many others. For more details on these applications, please see the
@ -162,7 +162,7 @@ For the avoidance of unclarity, the parameters to be determined are:
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
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 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).
@ -195,7 +195,7 @@ Below we'll discuss the rules one-by-one:
The set of data committed to is a superset of data which can impact the TXID of the transaction,
other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels
are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that
may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more
@ -341,7 +341,7 @@ programs.
RIPEMD160, a 20 byte hash, might also be a viable hash in some contexts and has some benefits. For fee efficiency,
RIPEMD160 saves 12 bytes. However, RIPEMD160 was not chosen for BIP-119 because it introduces
risks around the verification of programs created by third parties to be subject to a
risks around the verification of programs created by third parties to be subject to a
[birthday-attack https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh] on
transaction preimages.
@ -523,11 +523,11 @@ CHECKTEMPLATEVERIFY has benefits in terms of script size (depending on choice of
PK, SIGHASH_ANYPREVOUTANYSCRIPT may use about 2x-3x the bytes) and verification
speed, as OP_CHECKTEMPLATEVERIFY requires only hash computation rather than
signature operations. This can be significant when constructing large payment
trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise
trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise
benefit in that it provides a robust pathway for future template upgrades.
OP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate
CHECKTEMPLATEVERIFY. However such constructions are more complicated to use
CHECKTEMPLATEVERIFY. However such constructions are more complicated to use
than CHECKTEMPLATEVERIFY, and encumbers additional verification overhead absent
from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential
recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin.
@ -545,7 +545,7 @@ the future as well as synergies with other possible upgrades.
=====CHECKTEMPLATEVERIFY Versions=====
OP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments.
In the future, meaning could be ascribed to other length arguments. For
In the future, meaning could be ascribed to other length arguments. For
example, a 33-byte argument could just the last byte as a control program. In
that case, DefaultCheckTemplateVerifyHash could be computed when the flag byte
is set to CTVHASH_ALL. Other programs could be added similar to SIGHASH_TYPEs.