mirror of
https://github.com/bitcoin/bips.git
synced 2024-11-19 01:40:05 +01:00
BIP-119: Update Motivations and describe vaults alternatives better
This commit is contained in:
parent
4c6389f843
commit
4479187baf
@ -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===
|
||||
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.
|
||||
|
||||
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.
|
||||
<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]
|
||||
|
BIN
bip-0119/vaultanim.gif
Normal file
BIN
bip-0119/vaultanim.gif
Normal file
Binary file not shown.
After Width: | Height: | Size: 929 KiB |
Loading…
Reference in New Issue
Block a user