diff options
Diffstat (limited to 'bip-0119.mediawiki')
| -rw-r--r-- | bip-0119.mediawiki | 86 |
1 files changed, 63 insertions, 23 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 1068e24..09e8564 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== @@ -230,7 +253,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. @@ -255,8 +282,15 @@ standardized later as policy changes. ==Reference Implementation== -A reference implementation and tests are available here: -https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify. +A reference implementation and tests are available here in the PR to Bitcoin Core https://github.com/bitcoin/bitcoin/pull/21702. + +It is not ideal to link to a PR, as it may be rebased and changed, but it is the best place to find +the current implementation and review comments of others. +A recent commit hash in that PR including tests and vectors can be found here https://github.com/jeremyrubin/bitcoin/commit/3109df5616796282786706738994a5b97b8a5a38. +Once the PR is merged, this BIP should be updated to point to the specific code released. + +Test vectors are available in [/bip-0119/vectors the bip-0119/vectors +directory] for checking compatibility with the refrence implementation and BIP. ==Rationale== @@ -333,13 +367,15 @@ spent. In general, using CHECKTEMPLATEVERIFY with more than one input is difficu and exposes subtle issues, so multiple inputs should not be used except in specific applications. -In principal, committing to the Sequences Hash (below) implicitly commits to the number of inputs, +In principle, committing to the Sequences Hash (below) implicitly commits to the number of inputs, making this field strictly redundant. However, separately committing to this number makes it easier to construct DefaultCheckTemplateVerifyHash from script. -We treat the number of inputs as a `uint32_t` because signature checking code expects nIn to be an -`unsigned int`, even though in principal a transaction can encode more than a `uint32_t`'s worth of -inputs. +We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decoding logic limits vectors +to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also +friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that +the max inputs in a block is further restricted by the block size to around 25,000, which would fit +into a `uint16_t`, but that is an uneccessary abstraction leak. =====Committing to the Sequences Hash===== @@ -355,12 +391,14 @@ script. =====Committing to the Number of Outputs===== -In principal, committing to the Outputs Hash (below) implicitly commits to the number of outputs, +In principle, committing to the Outputs Hash (below) implicitly commits to the number of outputs, making this field strictly redundant. However, separately committing to this number makes it easier to construct DefaultCheckTemplateVerifyHash from script. -We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`, even -though in principal a transaction could encode more outputs. +We treat the number of outputs as a `uint32_t` because a `COutpoint` index is a `uint32_t`. +Further, Bitcoin's consensus decoding logic limits vectors to `MAX_SIZE=33554432` and that is +larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using +Bitcoin's current math opcodes, should `OP_CAT` be added. =====Committing to the outputs hash===== @@ -682,6 +720,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] |