1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00

BIP-119: Update Motivations and describe vaults alternatives better

This commit is contained in:
Jeremy Rubin 2021-12-22 19:15:28 -08:00
parent 4c6389f843
commit 4479187baf
2 changed files with 37 additions and 12 deletions

View File

@ -111,27 +111,50 @@ sensitivity of the lightning protocol on contested channel close.
===Wallet Vaults=== ===Wallet Vaults===
When greater security is required for cold storage solutions, there can be This section will detail two variants of wallet vault that can be built using
default script paths that move funds from one target to another target. CTV. Wallet vaults are a useful tool when greater security is required for
For example, a cold wallet can be set up where one customer support desk can, 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 without further authorization, move a portion of the funds (using multiple
pre-set amounts) into a lukewarm wallet operated by an isolated support desk. 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 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. remainder back to cold storage with a similar withdrawal mechanism in place.
This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY This is all possible without CHECKTEMPLATEVERIFY, but CHECKTEMPLATEVERIFY
eliminates the need for coordination and online signers, as well as reducing the eliminates the need for coordination and online signers, as well as reducing
ability for a support desk to improperly move funds. the ability for a support desk to improperly move funds. Furthermore, all such
Furthermore, all such designs can be combined with relative time locks to give designs can be combined with relative time locks to give time for compliance
time for compliance and risk desks to intervene. 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> <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 <img src="bip-0119/vaultanim.gif" align="middle"></img>
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 ===CoinJoin / Payment Pools / Join Pools ===
that output, they only have to verify their own sub-tree will pay them.
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== ==Detailed Specification==
@ -642,6 +665,8 @@ for older node versions that can be patched but not upgraded to a newer major re
== References == == References ==
*[https://utxos.org utxos.org informational site] *[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://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://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] *[https://cyber.stanford.edu/sites/g/files/sbiybj9936/f/jeremyrubin.pdf Structuring Multi Transaction Contracts in Bitcoin]

BIN
bip-0119/vaultanim.gif Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 929 KiB