diff options
Diffstat (limited to 'bip-0345.mediawiki')
| -rw-r--r-- | bip-0345.mediawiki | 25 |
1 files changed, 12 insertions, 13 deletions
diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki index c0baeb2..2276bd1 100644 --- a/bip-0345.mediawiki +++ b/bip-0345.mediawiki @@ -17,20 +17,19 @@ == Introduction == -This BIP proposes new tapscript opcodes, <code>OP_VAULT</code> and -<code>OP_VAULT_RECOVER</code>, that add consensus support for a specialized -covenant. These opcodes, in conjunction with +This BIP proposes two new tapscript opcodes that add consensus support for a specialized +covenant: <code>OP_VAULT</code> and <code>OP_VAULT_RECOVER</code>. These opcodes, in conjunction with <code>OP_CHECKTEMPLATEVERIFY</code> ([https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki BIP-0119]), allow users to enforce a delay period before designated coins may be spent to an arbitrary destination, with the exception of a prespecified "recovery" path. At any time prior to final withdrawal, the coins can be spent to the -prespecified path. +recovery path. === Motivation === -The hazard of custodying Bitcoin is well known. Users of Bitcoin must go to +The hazard of custodying Bitcoin is well-known. Users of Bitcoin must go to significant effort to secure their private keys, and hope that once provisioned their custody system does not yield to any number of evolving and persistent threats. Users have little means to intervene once a compromise is @@ -45,8 +44,8 @@ usable for custodians of any size with minimal complication. ==== Example uses ==== -An individual custodying Bitcoin uses the common "single signature and -passphrase" configuration with a hardware wallet. They are concerned about the +A common configuration for an individual custodying Bitcoin is a "single signature and +passphrase" with a hardware wallet. They are concerned about the risk associated with relying on a single manufacturer for key management as well as physical access to the hardware, so they generate a new key that is highly secure, but would be impractical for daily use. For example the key @@ -66,7 +65,7 @@ them to the highly secure recovery path, but spending the coins on a daily basis works in the same way it did prior to vaulting - aside from the spend delay. -The recovery key could be any number of things: a 2-of-3 multisig with keys +The recovery key could be any Bitcoin script policy: a 2-of-3 multisig with keys that live on different devices, a 3-of-5 with socially distributed keys, a Taproot construction that incorporates one of these methods along with a time-delayed fallback to an "easier" recovery method, in case the highly secure @@ -76,7 +75,7 @@ Institutional custodians of Bitcoin would likely use vaults in similar fashion. ===== Provable timelocks ===== -This proposal provides a solution to the +This proposal provides a mitigation to the [https://web.archive.org/web/20230210123933/https://xkcd.com/538/ "$5 wrench attack."] By setting the spend delay to, say, a week, and using as the recovery path a script that enforces a longer relative timelock, the owner of the vault can @@ -148,7 +147,7 @@ The design goals of the proposal are: * '''dynamic fee management''' that, like dynamic targets, defers the specification of fee rates and source to unvault time rather than vault creation time. These goals are accompanied by basic safety considerations (e.g. not being -vulnerable to pinning) and a desire for concision, both in terms of the number +vulnerable to mempool pinning) and a desire for concision, both in terms of the number of outputs created as well as script sizes. This proposal is designed to be compatible with any future sighash modes (e.g. <code>SIGHASH_GROUP</code>) or fee management strategies (e.g. [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html transaction sponsors]) that may be introduced. Use of these opcodes will benefit from, but do not strictly rely on, [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html v3 transaction relay] and [https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki ephemeral anchors]. @@ -166,7 +165,7 @@ The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible withdrawal by allowing a spending transaction to replace the <code>OP_VAULT</code> tapleaf with a prespecified script template, allowing for some parameters to be set at spend (trigger) time. All other leaves in the -taptree must be unchanged, which preserves the recovery path as well as any +taptree must be unchanged in the destination output, which preserves the recovery path as well as any other spending conditions originally included in the vault. This is similar to the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021]. @@ -564,9 +563,9 @@ coins they wish to monitor; the watchtower would then alert the user if any coins matching the filter move, and the user would be responsible for ignoring false positives and handling recovery initiation. -=== Script descriptors === +=== Output descriptors === -Script descriptors for vault-related outputs will be covered in a subsequent BIP. +Output descriptors for vault-related outputs will be covered in a subsequent BIP. == Deployment == |