BIP-119: Update Motivations and describe vaults alternatives better

1 files changed, 38 insertions, 13 deletions

diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index e887caf..dd8df49 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -111,27 +111,50 @@ sensitivity of the lightning protocol on contested channel close.
 
 ===Wallet Vaults===
 
-When greater security is required for cold storage solutions, there can be
-default script paths that move funds from one target to another target.
-For example, a cold wallet can be set up where one customer support desk can,
+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.
+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>
 
-===CoinJoin===
-
-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.
+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".
 
 ==Detailed Specification==
 
@@ -642,6 +665,8 @@ for older node versions that can be patched but not upgraded to a newer major re
 == References ==
 
 *[https://utxos.org utxos.org informational site]
+*[https://learn.sapio-lang.org Sapio Bitcoin smart contract language]
+*[https://rubin.io/advent21 27 Blog Posts on building smart contracts with Sapio and CTV, including examples described here.]
 *[https://www.youtube.com/watch?v=YxsjdIl0034&t=2451 Scaling Bitcoin Presentation]
 *[https://bitcoinops.org/en/newsletters/2019/05/29/ Optech Newsletter Covering OP_CHECKOUTPUTSHASHVERIFY]
 *[https://cyber.stanford.edu/sites/g/files/sbiybj9936/f/jeremyrubin.pdf Structuring Multi Transaction Contracts in Bitcoin]