diff options
Diffstat (limited to 'bip-0119.mediawiki')
| -rw-r--r-- | bip-0119.mediawiki | 57 |
1 files changed, 43 insertions, 14 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 91471df..223e8dd 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== @@ -223,7 +246,11 @@ A PayToBareDefaultCheckTemplateVerifyHash output matches the following template: ==Deployment== -Deployment should be done via BIP 9 VersionBits deployed through Speedy Trial. +Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial. +The Bitcoin Core reference implementation includes the below parameters, +configured to match Speedy Trial, as that is the current activation mechanism +implemented in Bitcoin Core. Should another method become favored by the wider +Bitcoin comminity, that might be used instead. The start time and bit in the implementation are currently set to bit 5 and NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft. @@ -645,6 +672,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] |