mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-02-22 23:08:01 +01:00
Code Issues Projects Releases Wiki Activity

few fixups

Browse source
This commit is contained in:
Greg Sanders 2023-03-28 15:08:03 -04:00
parent 29345a10f0
commit 0b0674c546
1 changed files with 12 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
bip-0345.mediawiki
View file

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