Skip to content

Commit 4479187

Browse files
committed
BIP-119: Update Motivations and describe vaults alternatives better
1 parent 4c6389f commit 4479187

File tree

2 files changed

+38
-13
lines changed

2 files changed

+38
-13
lines changed

bip-0119.mediawiki

Lines changed: 38 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -111,27 +111,50 @@ sensitivity of the lightning protocol on contested channel close.
111111

112112
===Wallet Vaults===
113113

114-
When greater security is required for cold storage solutions, there can be
115-
default script paths that move funds from one target to another target.
116-
For example, a cold wallet can be set up where one customer support desk can,
114+
This section will detail two variants of wallet vault that can be built using
115+
CTV. Wallet vaults are a useful tool when greater security is required for
116+
cold storage solutions, providing default transactional paths that move funds
117+
from one's cold storage to a hot wallet.
118+
119+
One type of cold wallet can be set up such that a customer support desk can,
117120
without further authorization, move a portion of the funds (using multiple
118121
pre-set amounts) into a lukewarm wallet operated by an isolated support desk.
119122
The support desk can then issue some funds to a hot wallet, and send the
120123
remainder back to cold storage with a similar withdrawal mechanism in place.
121124
This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY
122-
eliminates the need for coordination and online signers, as well as reducing the
123-
ability for a support desk to improperly move funds.
124-
Furthermore, all such designs can be combined with relative time locks to give
125-
time for compliance and risk desks to intervene.
125+
eliminates the need for coordination and online signers, as well as reducing
126+
the ability for a support desk to improperly move funds. Furthermore, all such
127+
designs can be combined with relative time locks to give time for compliance
128+
and risk desks to intervene. This is a 'Coins at Rest' or 'Optically Isolated'
129+
vault, and is shown below.
126130

127131
<img src="bip-0119/vaults.svg" align="middle"></img>
128132

129-
===CoinJoin===
130-
131-
CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than previously because
132-
participants agree on a single output which pays all participants, which will be lower fee than
133-
before. Further Each participant doesn't need to know the totality of the outputs committed to by
134-
that output, they only have to verify their own sub-tree will pay them.
133+
An alternative design for vaults is also highly effective and simpler to
134+
implement in Sapio, a smart contract programming language. In this design, the
135+
user commits to a single UTXO that contains a program for an annuity of
136+
withdrawals from cold storage to a hot wallet. At any time, the remaining
137+
balance for the annuity can be cancelled and funds locked entirely in cold
138+
storage. The withdrawals to the hot wallet can be 'cancelled' before a maturity
139+
date to ensure the action was authorized. These sort of vaults strongly benefit
140+
from non-interactivity because the withdrawal program can be set up with cold
141+
keys that are permanently offline, except in case of emergency. The image below
142+
shows an instance of this type of wallet vault created with Sapio in Sapio
143+
Studio. These types of wallet vault can also be chained together by taking
144+
advantage of CTV's scriptSig commitment. This type of vault is a 'Coins in Motion'
145+
variant where the coins move along the control path.
146+
147+
<img src="bip-0119/vaultanim.gif" align="middle"></img>
148+
149+
===CoinJoin / Payment Pools / Join Pools ===
150+
151+
CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than
152+
previously because participants agree on a single output which pays all
153+
participants, which will be lower fee than before. Further Each participant
154+
doesn't need to know the totality of the outputs committed to by that output,
155+
they only have to verify their own sub-tree will pay them. These trees can
156+
then, using a top-level Schnorr key, be interactively updated on a rolling basis
157+
forming a "Payment Pool".
135158

136159
==Detailed Specification==
137160

@@ -642,6 +665,8 @@ for older node versions that can be patched but not upgraded to a newer major re
642665
== References ==
643666

644667
*[https://utxos.org utxos.org informational site]
668+
*[https://learn.sapio-lang.org Sapio Bitcoin smart contract language]
669+
*[https://rubin.io/advent21 27 Blog Posts on building smart contracts with Sapio and CTV, including examples described here.]
645670
*[https://www.youtube.com/watch?v=YxsjdIl0034&t=2451 Scaling Bitcoin Presentation]
646671
*[https://bitcoinops.org/en/newsletters/2019/05/29/ Optech Newsletter Covering OP_CHECKOUTPUTSHASHVERIFY]
647672
*[https://cyber.stanford.edu/sites/g/files/sbiybj9936/f/jeremyrubin.pdf Structuring Multi Transaction Contracts in Bitcoin]

bip-0119/vaultanim.gif

929 KB
Loading

0 commit comments

Comments
 (0)