diff options
Diffstat (limited to 'bip-0119.mediawiki')
| -rw-r--r-- | bip-0119.mediawiki | 145 |
1 files changed, 26 insertions, 119 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 304f228..67e21b2 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. 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. 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 +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 +references. + ==Detailed Specification== @@ -725,6 +624,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=== |