diff options
| -rw-r--r-- | bip-0032.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0119.mediawiki | 57 | ||||
| -rw-r--r-- | bip-0119/vaultanim.gif | bin | 0 -> 951723 bytes | |||
| -rw-r--r-- | bip-0174.mediawiki | 22 | ||||
| -rw-r--r-- | bip-0341.mediawiki | 4 |
5 files changed, 46 insertions, 39 deletions
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index ee09b68..b441658 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -201,7 +201,7 @@ In addition to the expectations from the EC public-key cryptography itself: the intended security properties of this standard are: * Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. * Given any number (2 ≤ N ≤ 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (k<sub>par</sub>,c<sub>par</sub>) such that for each j in (0..N-1) CKDpriv((k<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(k<sub>i<sub>j</sub></sub>,c<sub>i<sub>j</sub></sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512. -Note however that the following properties does not exist: +Note however that the following properties do not exist: * Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i. * Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a non-hardened child private key (k<sub>i</sub>), it is hard to find k<sub>par</sub>. 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] diff --git a/bip-0119/vaultanim.gif b/bip-0119/vaultanim.gif Binary files differnew file mode 100644 index 0000000..a6b3082 --- /dev/null +++ b/bip-0119/vaultanim.gif diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 27e475f..295a9a3 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -171,17 +171,6 @@ The currently defined global types are as follows: | 2 | [[bip-0370.mediawiki|370]] |- -| SIGHASH_SINGLE Inputs -| <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07</tt> -| None -| No key data -| <tt><bit vector></tt> -| A bit vector representing which input indexes use SIGHASH_SINGLE. If the bit for an index is set to 1, then the input and output pair at that index are tied together with SIGHASH_SINGLE and must be moved together. -| -| 0 -| 2 -| [[bip-0370.mediawiki|370]] -|- | PSBT Version Number | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> | None @@ -599,17 +588,6 @@ determine which outputs are change outputs and verify that the change is returni | 0, 2 | [[bip-0371.mediawiki|371]] |- -| Taproot Leaf Script -| <tt>PSBT_OUT_TAP_LEAF_SCRIPT = 0x06</tt> -| <tt><control block></tt> -| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf. -| <tt><script></tt> -| The script for this leaf as would be provided in the witness stack. -| -| -| 0, 2 -| [[bip-0371.mediawiki|371]] -|- | Taproot Key BIP 32 Derivation Path | <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt> | <tt><xonlypubkey></tt> diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki index 693233a..fa9bb15 100644 --- a/bip-0341.mediawiki +++ b/bip-0341.mediawiki @@ -78,7 +78,7 @@ The following rules only apply when such an output is being spent. Any other out ** If ''t ≥ 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141'' (order of secp256k1), fail. ** Let ''Q = P + int(t)G''. ** If ''q ≠ x(Q)'' or ''c[0] & 1 ≠ y(Q) mod 2'', fail<ref>'''Why is it necessary to reveal a bit in a script path spend and check that it matches the parity of the Y coordinate of ''Q''?''' The parity of the Y coordinate is necessary to lift the X coordinate ''q'' to a unique point. While this is not strictly necessary for verifying the taproot commitment as described above, it is necessary to allow batch verification. Alternatively, ''Q'' could be forced to have an even Y coordinate, but that would require retrying with different internal public keys (or different messages) until ''Q'' has that property. There is no downside to adding the parity bit because otherwise the control block bit would be unused.</ref>. -** Execute the script, according to the applicable script rules<ref>'''What are the applicable script rules in script path spends?''' [[bip-0342.mediawiki|BIP342]] specifies validity rules that apply for leaf version 0xc0, but future proposals can introduce rules for other leaf versions.</ref>, using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack. +** Execute the script, according to the applicable script rules<ref>'''What are the applicable script rules in script path spends?''' [[bip-0342.mediawiki|BIP342]] specifies validity rules that apply for leaf version 0xc0, but future proposals can introduce rules for other leaf versions.</ref>, using the witness stack elements excluding the script ''s'', the control block ''c'', and the annex ''a'' if present, as initial stack. This implies that for the future leaf versions (non-''0xC0'') the execution must succeed.<ref>'''Why we need to success on future leaf version validation''' This is required to enable future leaf versions as soft forks</ref>. ''q'' is referred to as ''taproot output key'' and ''p'' as ''taproot internal key''. @@ -138,7 +138,7 @@ In summary, the semantics of the [[bip-0143.mediawiki|BIP143]] sighash types rem To validate a signature ''sig'' with public key ''q'': * If the ''sig'' is 64 bytes long, return ''Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(0x00, 0)), sig)''<ref>'''Why is the input to ''hash<sub>TapSighash</sub>'' prefixed with 0x00?''' This prefix is called the sighash epoch, and allows reusing the ''hash<sub>TapSighash</sub>'' tagged hash in future signature algorithms that make invasive changes to how hashing is performed (as opposed to the ''ext_flag'' mechanism that is used for incremental extensions). An alternative is having them use a different tag, but supporting a growing number of tags may become undesirable.</ref>, where ''Verify'' is defined in [[bip-0340.mediawiki#design|BIP340]]. -* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 0)), sig[0:64])''. +* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00<ref>'''Why can the <code>hash_type</code> not be <code>0x00</code> in 65-byte signatures?''' Permitting that would enable malleating (by third parties, including miners) 64-byte signatures into 65-byte ones, resulting in a different `wtxid` and a different fee rate than the creator intended.</ref> and Verify(q, hash<sub>TapSighash</sub>(0x00 || SigMsg(sig[64], 0)), sig[0:64])''. * Otherwise, fail<ref>'''Why permit two signature lengths?''' By making the most common type of <code>hash_type</code> implicit, a byte can often be saved.</ref>. == Constructing and spending Taproot outputs == |
