diff options
Diffstat (limited to 'bip-0119.mediawiki')
| -rw-r--r-- | bip-0119.mediawiki | 157 |
1 files changed, 32 insertions, 125 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index c2d9912..aa226d0 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -39,125 +39,24 @@ 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. 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. - -A few examples are described below, which should be the subject of future non-consensus -standardization efforts. - -===Congestion Controlled Transactions=== - -When there is a high demand for blockspace it becomes very expensive to make transactions. A large -volume payment processor may aggregate all their payments into a single O(1) transaction commitment -for purposes of confirmation using CHECKTEMPLATEVERIFY. Then, some time later, the payments can -be expanded out of that UTXO when the demand for blockspace is decreased. These payments can be -structured in a tree-like fashion to reduce individual costs of redemption. - -The below chart showcases the structure of these transactions in comparison to -normal transactions and batched transactions. - -<img src="bip-0119/states.svg" align="middle"></img> - -A simulation is shown below of what impact this could have on mempool backlog -given 5% network adoption, and 50% network adoption. The code for the simulation -is provided in this BIP's subdirectory. - -<img src="bip-0119/five.png" align="middle"></img> -<img src="bip-0119/fifty.png" align="middle"></img> - -===Payment Channels=== - -There are numerous payment channel related uses. - -====Batched Channel Creation==== - -Using CHECKTEMPLATEVERIFY for Batched Channel Creation is similar to the use for Congestion Control, -except the leaf node transactions are channels instead of plain payments. The channel can be between -the sender and recipient or a target of recipient's choice. Using an CHECKTEMPLATEVERIFY, the -recipient may give the sender an address which makes a tree of channels unbeknownst to them. -These channels are time insensitive for setup, as all punishments are relative timelocked to the -penultimate transaction node. -Thus, coins sent using a congestion controlled transaction can still enjoy instant liquidity. - -====Non-Interactive Channels==== - -When opening a traditional payment channel, both parties to the channel must participate. This is -because the channel uses pre-signed multi-sig transactions to ensure that a channel can always be -exited by either party, before entering. -With CHECKTEMPLATEVERIFY, it’s possible for a single party to construct a channel which either -party can exit from without requiring signatures from both parties. -These payment channels can operate in one direction, paying to the channel "listener" without need -for their private key to be online. -<img src="bip-0119/nic.svg" align="middle"></img> - -====Increased Channel Routes==== - -In the Lightning Network protocol, Hashed Time Locked Contracts (HTLCS) are used in the construction -of channels. A new HTLC is required per route that the channel is serving in. -In BOLT #2, this maximum number of HTLCs in a channel is hard limited to 483 as the maximum safe -size to prevent the transaction from being too large to be valid. In common software implementations -such as LND, this limit is set much lower to 12 HTLCS. This is because accepting a larger number of -HTLCS makes it more difficult for transactions to confirm during congested periods as they must pay -higher fees. -Therefore, similarly to how congestion control is handled for normal transaction, lightning channel -updates can be done across an CHECKTEMPLATEVERIFY tree, allowing nodes to safely use many more -HTLCS. -Because each HTLC can have its own relative time lock in the tree, this also improves the latency -sensitivity of the lightning protocol on contested channel close. - -===Wallet Vaults=== - -This section will detail two variants of wallet vault that can be built using -CTV. Wallet vaults are a useful tool when greater security is required for -cold storage solutions, providing default transactional paths that move funds -from one's cold storage to a hot wallet. - -One type of cold wallet can be set up such that a customer support desk can, -without further authorization, move a portion of the funds (using multiple -pre-set amounts) into a lukewarm wallet operated by an isolated support desk. -The support desk can then issue some funds to a hot wallet, and send the -remainder back to cold storage with a similar withdrawal mechanism in place. -This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY -eliminates the need for coordination and online signers, as well as reducing -the ability for a support desk to improperly move funds. Furthermore, all such -designs can be combined with relative time locks to give time for compliance -and risk desks to intervene. This is a 'Coins at Rest' or 'Optically Isolated' -vault, and is shown below. - -<img src="bip-0119/vaults.svg" align="middle"></img> - -An alternative design for vaults is also highly effective and simpler to -implement in Sapio, a smart contract programming language. In this design, the -user commits to a single UTXO that contains a program for an annuity of -withdrawals from cold storage to a hot wallet. At any time, the remaining -balance for the annuity can be cancelled and funds locked entirely in cold -storage. The withdrawals to the hot wallet can be 'cancelled' before a maturity -date to ensure the action was authorized. These sort of vaults strongly benefit -from non-interactivity because the withdrawal program can be set up with cold -keys that are permanently offline, except in case of emergency. The image below -shows an instance of this type of wallet vault created with Sapio in Sapio -Studio. These types of wallet vault can also be chained together by taking -advantage of CTV's scriptSig commitment. This type of vault is a 'Coins in Motion' -variant where the coins move along the control path. - -<img src="bip-0119/vaultanim.gif" align="middle"></img> - -===CoinJoin / Payment Pools / Join Pools === - -CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than -previously because participants agree on a single output which pays all -participants, which will be lower fee than before. Further each participant -doesn't need to know the totality of the outputs committed to by that output, -they only have to verify their own sub-tree will pay them. These trees can -then, using a top-level Schnorr key, be interactively updated on a rolling basis -forming a "Payment Pool". +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. + ==Detailed Specification== @@ -306,7 +205,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). @@ -339,7 +238,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 @@ -485,7 +384,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. @@ -667,11 +566,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. @@ -689,7 +588,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. @@ -768,6 +667,14 @@ for older node versions that can be patched but not upgraded to a newer major re *[https://fc16.ifca.ai/bitcoin/papers/MES16.pdf Bitcoin Covenants] *[https://bitcointalk.org/index.php?topic=278122.0 CoinCovenants using SCIP signatures, an amusingly bad idea.] *[https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf Enhancing Bitcoin Transactions with Covenants] +*[https://github.com/jamesob/simple-ctv-vault Simple CTV Vaults] +*[https://github.com/kanzure/python-vaults Python Vaults] +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html CTV Dramatically Improves DLCs] +*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020225.html Calculus of Covenants] +*[https://rubin.io/bitcoin/2021/12/10/advent-13/ Payment Pools with CTV] +*[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] ===Note on Similar Alternatives=== |