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

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===