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 #1792 from JeremyRubin/119-edits-2025

Browse Source 
[BIP-119] language overhaul & cleanup
This commit is contained in:
Jon Atack 2025-03-21 08:18:30 -06:00 committed by GitHub
commit 335edb3519
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 75 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

155
bip-0119.mediawiki
View File

@ -15,10 +15,6 @@
This BIP proposes a new opcode, OP_CHECKTEMPLATEVERIFY, to be activated
as a change to the semantics of OP_NOP4.
The new opcode has applications for transaction congestion control and payment
channel instantiation, among others, which are described in the Motivation
section of this BIP.
==Summary==
OP_CHECKTEMPLATEVERIFY uses opcode OP_NOP4 (0xb3) as a soft fork upgrade.
@ -39,23 +35,11 @@ The recommended standardness rules additionally:
==Motivation==
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. Covenants have historically been widely
considered to be unfit for Bitcoin because they are too complex to implement
and risk reducing the fungibility of coins bound by them.
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
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
references.
This BIP introduces a transaction template, a simple spending restriction that
pattern matches a transaction against a hashed transaction specification.
OP_CHECKTEMPLATEVERIFY reduces many of the trust, interactivity, and storage
requirements inherent with the use of pre-signing in applications.
For more details on applications, please see the references.
==Detailed Specification==
@ -188,22 +172,7 @@ def is_pay_to_bare_default_check_template_verify_hash(self):
==Deployment==
Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.
The Bitcoin Core reference implementation includes the below parameters,
configured to match Speedy Trial, as that is the current activation mechanism
implemented in Bitcoin Core. Should another method become favored by the wider
Bitcoin community, that might be used instead.
The start time and bit in the implementation are currently set to bit 5 and
NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft.
For the avoidance of unclarity, the parameters to be determined are:
// Deployment of CTV (BIP 119)
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].bit = 5;
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nStartTime = Consensus::BIP9Deployment::NEVER_ACTIVE;
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0;
Activation logic is elided from this BIP and is more appropriately discussed elsewhere.
Until BIP-119 reaches ACTIVE state and the
SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to)
@ -212,9 +181,10 @@ a NOP for consensus (during block validation).
In order to facilitate using CHECKTEMPLATEVERIFY, the common case of a
PayToBareDefaultCheckTemplateVerifyHash
with no scriptSig data may (is recommended to) 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 bare scripts may be
standardized later as policy changes at the preference of the implementer.
==Reference Implementation==
A reference implementation and tests are available here in the PR to Bitcoin Core https://github.com/bitcoin/bitcoin/pull/21702.
@ -229,8 +199,9 @@ directory] for checking compatibility with the reference implementation and BIP.
==Rationale==
The goal of CHECKTEMPLATEVERIFY is to be minimal impact on the existing codebase -- in the
future, as we become aware of more complex but shown to be safe use cases, new template types can be added.
OP_CHECKTEMPLATEVERIFY's design is a small code change and simple to analyze. It is
compatible with future upgrades if new template types are required
for more complex but demonstrably safe use cases.
Below we'll discuss the rules one-by-one:
@ -240,8 +211,8 @@ The set of data committed to is a superset of data which can impact the TXID of
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
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
are built using an LN-Symmetry-like protocol. Note that there may be other types of pre-signed contracts that
may or may not be able to use LN-Symmetry-like constructs, therefore making TXIDs predictable makes CTV more
composable with arbitrary sub-protocols.
=====Committing to the version and locktime=====
@ -442,18 +413,20 @@ able to express a "don't care" index easily (e.g., for decentralized kickstarter
this value is placed last.
===Design Tradeoffs and Risks===
Covenants have historically been controversial given their potential for fungibility risks -- coins
could be minted which have a permanent restriction on how they may or may not be spent or required
to propagate metadata.
In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to simple templates. The
structure of CHECKTEMPLATEVERIFY template is such that the outputs must be known exactly at the
time of construction. Based on a destructuring argument, it is only possible to create templates
which expand in a finite number of steps. Thus templated transactions are in theory as safe as
transactions which create all the inputs directly in this regard.
CHECKTEMPLATEVERIFY's design limits script authors to relatively precise template matching. The
structure of CHECKTEMPLATEVERIFY template is such that most of the transaction details must be known
exactly at the time of construction, with the exception of the inputs.
Furthermore, templates are restricted to be spendable as a known number of inputs only, preventing
unintentional introduction of the 'half spend' problem.
CHECKTEMPLATEVERIFY can be nested -- that is, a transaction that is created by spending an output with a
`<H> OP_CHECKTEMPLATEVERIFY` restriction may create outputs with `<X> OP_CHECKTEMPLATEVERIFY` restrictions.
This expansion is inherently finite, as re-creating an output with a script containing the hash `<H>` from a transaction
spending an output with the hash `<H>` creates a hash cycle. This can also be thought of as each template hash `<H>` having
a "path height" of the longest chain of possible unbroken `OP_CHECKTEMPLATEVERIFY` verifying transactions, and the path height is
strictly decreasing.
Furthermore, templates are restricted to be spendable as a known number of inputs only and
at a specific input index, preventing unintentional introduction of the 'half spend' problem.
Templates, as restricted as they are, bear some risks.
@ -482,7 +455,7 @@ over all variable length fields in a transaction.
For CTV, the Denial-of-Service exposure and validation costs are relatively clear. Implementers must be careful
to correctly code CTV to make use of existing caches and cache the (new for CTV) computations over scriptSigs.
Other more flexible covenant proposals may have a more difficult time solving DoS issues as more complex computations may
Other more flexible proposals may have a more difficult time solving DoS issues as more complex template computations may
be less cacheable and expose issues around quadratic hashing, it is a tradeoff CTV makes in favor of cheap and secure
validation at the expense of flexibility. For example, if CTV allowed the hashing only select outputs by a bitmask,
caching of all combinations of outputs would not be possible and would cause a quadratic hashing DoS vulnerability.
@ -537,23 +510,23 @@ consensus-valid transaction may be caused, leading to a potential loss of funds.
====Feature Redundancy====
CHECKTEMPLATEVERIFY templates are substantially less risky than other covenant systems. If
implemented, other covenant systems could make the CHECKTEMPLATEVERIFY's functionality redundant.
There are other opcodes that, if implemented, could make the CHECKTEMPLATEVERIFY's functionality redundant.
However, given CHECKTEMPLATEVERIFY's simple semantics and low on chain cost it's likely that it
would continue to be favored even if redundant with other capabilities.
would continue to be favored even if redundant with other capabilities. Or, in the case of opcodes
such as OP_VAULT, OP_CHECKCONTRACTVERIFY, and OP_TXHASH, OP_CHECKTEMPLATEVERIFY is a part of their
currently proposed implementations.
More powerful covenants like those proposed by MES16, would also bring some benefits in terms of
improving the ability to adjust for things like fees rather than relying on child-pays-for-parent or
other mechanisms. However, these features come at substantially increased complexity and room for
unintended behavior.
More powerful opcodes, like OP_COV proposed in MES16 or OP_TXHASH, would also bring some benefits in terms of
improving the ability to pay fees endogenously rather than relying on exogenous child-pays-for-parent or
other fee paying mechanisms such as transaction sponsors. However, these features come at substantially
increased complexity and room for behaviors unintended by the application developer.
Alternatively, SIGHASH_ANYPREVOUTANYSCRIPT based covenant designs can implement
something similar to templates, via a scriptPubKey like:
Alternatively, SIGHASH_ANYPREVOUTANYSCRIPT can be used to implement something similar to templates,
via a scriptPubKey like:
<sig of desired TX with PK and fixed nonce R || SIGHASH_ANYPREVOUTANYSCRIPT <PK with public SK> OP_CHECKSIG
SIGHASH_ANYPREVOUTANYSCRIPT bears additional technical and implementation risks
that may preclude its viability for inclusion in Bitcoin, but the capabilities
SIGHASH_ANYPREVOUTANYSCRIPT capabilities
above are similar to what CHECKTEMPLATEVERIFY offers. The key functional
difference between SIGHASH_ANYPREVOUTANYSCRIPT and OP_CHECKTEMPLATEVERIFY is
that OP_CHECKTEMPLATEVERIFY restricts the number of additional inputs and
@ -567,17 +540,17 @@ 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
benefit in that it provides a robust pathway for future template upgrades.
benefit in that it provides a robust pathway for future template upgrades, as proposed
in OP_TXHASH.
OP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate
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.
CHECKTEMPLATEVERIFY. However such constructions are more complicated to implement in application
scripts than CHECKTEMPLATEVERIFY, and encumber additional verification overhead absent
from CHECKTEMPLATEVERIFY.
Given the simplicity of this approach to implement and analyze, and the benefits realizable by user
applications, CHECKTEMPLATEVERIFY's template based approach is proposed in lieu of more complete
covenants system.
applications, CHECKTEMPLATEVERIFY's single template based approach is proposed in lieu of a generalized
system for specifying transactions in script.
====Future Upgrades====
@ -596,10 +569,13 @@ For example, CTVHASH_GROUP could read data from the Taproot Annex for
compatibility with SIGHASH_GROUP type proposals and allow dynamic malleability
of which indexes get hashed for bundling.
=====Eltoo with OP_CHECKSIGFROMSTACKVERIFY=====
The work done for the OP_TXHASH pre-BIP details one approach to upgrading the
OP_CHECKTEMPLATEVERIFY semantics.
=====OP_CHECKSIGFROMSTACKVERIFY=====
Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to
Bitcoin, it would be possible to implement a variant of Eltoo's floating
Bitcoin, it would be possible to implement a variant of LN-Symmetry's floating
transactions using the following script:
witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
@ -607,9 +583,14 @@ transactions using the following script:
Compared to SIGHASH_ANYPREVOUTANYSCRIPT, because OP_CHECKTEMPLATEVERIFY does not
allow something similar to SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol
implementers might elect to sign multiple versions of transactions with CPFP
Anchor Outputs or Inputs for paying fees or an alternative such as transaction
sponsors might be considered.
implementers might sign transactions with Ephemeral Anchors or additional Inputs
for paying fees or an alternative such as transaction sponsors might be considered.
Note that this use of OP_CHECKSIGFROMSTACKVERIFY and OP_CHECKTEMPLATEVERIFY, without the `<S+1> OP_CHECKLOCKTIMEVERIFY` ratchet,
enables a form of self-reproducing automata address with a one-time-trusted-setup, albeit with limited utility given the specifics
of OP_CHECKTEMPLATEVERIFY's DefaultCheckTemplateVerifyHash. In comparison, SIGHASH_ANYPREVOUT enables a more
powerful self-reproducing automata (colloquially called SpookChains), that uses a variety of combinations of SIGHASH flags
to be able to restrict state transitions based on amount.
=====OP_AMOUNTVERIFY=====
@ -626,8 +607,8 @@ apply for expected values and default to a keypath otherwise, e.g.:
=====OP_CAT/OP_SHA256STREAM=====
OP_CHECKTEMPLATEVERIFY is (as described in the Ordering of Fields section)
efficient for building covenants dynamically should Bitcoin get enhanced string
manipulation opcodes.
efficient for specifying transactions dynamically from script should Bitcoin get enhanced
data manipulation opcodes.
As an example, the following code checks an input index argument and
concatenates it to the template and checks the template matches the transaction.
@ -636,6 +617,9 @@ concatenates it to the template and checks the template matches the transaction.
<nVersion || nLockTime || input count || sequences hash || output count || outputs hash>
OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY
Note that were OP_CAT to be introduced with a size limit, e.g. 520 bytes, one would be limited
to use it to introspect transactions with 12 inputs and 12 outputs (depending on script type).
== Backwards Compatibility ==
OP_CHECKTEMPLATEVERIFY replaces a OP_NOP4 with stricter verification semantics. Therefore, scripts
@ -655,9 +639,16 @@ being "trusted" (i.e., eligible for spending before the transaction is confirmed
Backports of OP_CHECKTEMPLATEVERIFY can be trivially prepared (see the reference implementation)
for older node versions that can be patched but not upgraded to a newer major release.
== Script Compatibility ==
OP_CHECKTEMPLATEVERIFY is made available in all script versions. Application developers should
note that P2SH and P2SH Segwit, which reveal the program in the scriptSig, may not use `<H> CTV`
like fragments in their program as the scriptSig commitment creates a hash cycle.
== References ==
*[https://utxos.org utxos.org informational site]
*[https://covenants.info covenant informational site]
*[https://learn.sapio-lang.org Sapio Bitcoin smart contract language]
*[https://rubin.io/advent21 27 Blog Posts on building smart contracts with Sapio and CTV, including examples described here.]
*[https://www.youtube.com/watch?v=YxsjdIl0034&t=2451 Scaling Bitcoin Presentation]
@ -675,6 +666,10 @@ for older node versions that can be patched but not upgraded to a newer major re
*[https://rubin.io/bitcoin/2021/12/11/advent-14/ Channels with CTV]
*[https://rubin.io/bitcoin/2021/12/09/advent-12/ Congestion Control with CTV]
*[https://rubin.io/bitcoin/2021/12/07/advent-10/ Building Vaults on Bitcoin]
*[https://arkdev.info/ (Ark Labs) Ark Documentation]
*[https://docs.second.tech/protocol/intro/ (Second) Ark Documentation]
*[https://rubin.io/bitcoin/2022/09/14/drivechain-apo/ SpookChains]
*[https://github.com/bitcoin/bips/pull/1500 OP_TXHASH]
===Note on Similar Alternatives===
@ -684,8 +679,8 @@ in favor of CHECKTEMPLATEVERIFY. CHECKOUTPUTSHASHVERIFY did not commit to the
version or lock time and was thus insecure.
CHECKTEMPLATEVERIFY could also be implemented as an extension to Taproot, and was
proposed this way earlier. However, given that CHECKTEMPLATEVERIFY has no dependency
on Taproot, it is preferable to deploy it independently.
proposed this way earlier. However, particular applications may want to use OP_CHECKTEMPLATEVERIFY
in bare legacy scripts to maximize efficiency.
CHECKTEMPLATEVERIFY has also been previously referred to as OP_SECURETHEBAG, which is mentioned here
to aid in searching and referencing discussion on this BIP.