From de0ff362fc70a814978b6b11ee8887109a6bdc40 Mon Sep 17 00:00:00 2001 From: Jeremy Rubin Date: Tue, 10 May 2022 09:09:44 -0700 Subject: [PATCH 1/4] [BIP-119] Slim down motivation, add more references --- bip-0119.mediawiki | 141 ++++++++------------------------------------- 1 file changed, 24 insertions(+), 117 deletions(-) diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 304f228c..67e21b2f 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. +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. +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. -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. - - - -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. - - - - -===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. - - -====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. - - - -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. - - - -===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". ==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=== From b29a3d27bfd51949c6d7a98092b601f6b79abc49 Mon Sep 17 00:00:00 2001 From: Jeremy Rubin Date: Mon, 23 May 2022 09:28:01 -0700 Subject: [PATCH 2/4] [BIP-119] No double space after period, no trailing whitespaces --- bip-0119.mediawiki | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 67e21b2f..e043f7df 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -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. From c05f4042f47730a2b7f1e6e46f38db08ee774ff9 Mon Sep 17 00:00:00 2001 From: Jeremy Rubin Date: Mon, 23 May 2022 09:35:04 -0700 Subject: [PATCH 3/4] [BIP-119] Reword section on fungibility in motivation --- bip-0119.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index e043f7df..37cb4773 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -43,9 +43,9 @@ 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. +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 From cde2bd31a28a38a4f8b3acdc1929938655f0c966 Mon Sep 17 00:00:00 2001 From: Jeremy Rubin Date: Tue, 10 May 2022 10:14:49 -0700 Subject: [PATCH 4/4] [BIP-119] Minor wording fixups Co-authored-by: /dev/fd0 <94559964+1440000bytes@users.noreply.github.com> --- bip-0119.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 37cb4773..552e1f01 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -49,10 +49,10 @@ 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 +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 +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.