Merge pull request from JeremyRubin/ctv-updates2

Update CTV Motivations & Speedy Trial Information
This commit is contained in:
Luke Dashjr 2022-01-15 23:12:37 +00:00 committed by GitHub
commit 738bd8535c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 42 additions and 13 deletions

@ -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

Binary file not shown.

After

(image error) Size: 929 KiB