Merge pull request #1320 from JeremyRubin/delete-motivations-119

[BIP-119] Slim down motivation, add more references

Author: luke-jr

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==
 
@@ -263,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).
@@ -296,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
@@ -442,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.
 
@@ -624,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.
@@ -646,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.
@@ -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===