mirror of
https://github.com/bitcoin/bips.git
synced 2025-03-17 21:32:50 +01:00
Merge pull request #1257 from JeremyRubin/ctv-updates2
Update CTV Motivations & Speedy Trial Information
This commit is contained in:
commit
738bd8535c
@ -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==
|
||||||
|
|
||||||
@ -223,7 +246,11 @@ A PayToBareDefaultCheckTemplateVerifyHash output matches the following template:
|
|||||||
|
|
||||||
==Deployment==
|
==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
|
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.
|
NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft.
|
||||||
@ -642,6 +669,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
BIN
bip-0119/vaultanim.gif
Normal file
Binary file not shown.
After ![]() (image error) Size: 929 KiB |
Loading…
x
Reference in New Issue
Block a user