diff options
Diffstat (limited to 'bip-0345.mediawiki')
| -rw-r--r-- | bip-0345.mediawiki | 54 |
1 files changed, 27 insertions, 27 deletions
diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki index bc12f04..12980c4 100644 --- a/bip-0345.mediawiki +++ b/bip-0345.mediawiki @@ -52,23 +52,23 @@ A common configuration for an individual custodying Bitcoin is "single signature and passphrase" using a hardware wallet. A user with such a configuration might be concerned about the risk associated with relying on a single manufacturer for key management, as well as physical access to the -hardware. +hardware. This individual can use <code>OP_VAULT</code> to make use of a highly secure key as the unlikely recovery path, while using their existing signing procedure -as the withdrawal trigger key with a configured spend delay of e.g. 1 day. +as the withdrawal trigger key with a configured spend delay of e.g. 1 day. The recovery path key can be of a highly secure nature that might otherwise make it impractical for daily use. For example, the key could be generated in some analog fashion, or on an old computer that is then destroyed, with the private key replicated only in paper form. Or the key could be a 2-of-3 multisig using devices from different manufacturers. Perhaps the key is -geographically or socially distributed. +geographically or socially distributed. Since it can be any Bitcoin script policy, the recovery key can include a number of spending conditions, e.g. a time-delayed fallback to an "easier" recovery method, in case the highly secure key winds up being ''too'' highly -secure. +secure. The user can run software on their mobile device that monitors the blockchain for spends of the vault outpoints. If the vaulted coins move in an unexpected @@ -80,7 +80,7 @@ Institutional custodians of Bitcoin may use vaults in similar fashion. ===== Provable timelocks ===== -This proposal provides a mitigation 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 @@ -95,7 +95,7 @@ timelocked coins for perpetuity or relying on a trusted third party. Vaults in Bitcoin have been discussed formally since 2016 ([http://fc16.ifca.ai/bitcoin/papers/MES16.pdf MES16]) and informally since [https://web.archive.org/web/20160220215151/https://bitcointalk.org/index.php?topic=511881.0 2014]. The value of having a configurable delay period with recovery capability in light of an -unexpected spend has been widely recognized. +unexpected spend has been widely recognized. The only way to implement vaults given the existing consensus rules, aside from [https://github.com/revault emulating vaults with large multisig @@ -114,7 +114,7 @@ Unfortunately, this approach has a number of practical shortcomings: The deployment of a "precomputed" covenant mechanism like [https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki OP_CHECKTEMPLATEVERIFY] or -[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT] +[https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki SIGHASH_ANYPREVOUT] would both remove the necessity to use an ephemeral key, since the covenant is enforced on-chain, and lessen the burden of sensitive data storage, since the necessary transactions can be generated from a set of compact @@ -141,7 +141,7 @@ operational overhead using a specialized covenant. The design goals of the proposal are: -* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits. +* '''efficient reuse of an existing vault configuration.'''<ref>'''Why does this support address reuse?''' The proposal doesn't rely on or encourage address reuse, but certain uses are unsafe if address reuse cannot be handled - for example, if a custodian gives its users a vault address to deposit to, it cannot enforce that those users make a single deposit for each address.</ref> A single vault configuration, whether the same literal <code>scriptPubKey</code> or not, should be able to “receive” multiple deposits. * '''batched operations''' for recovery and withdrawal to allow managing multiple vault coins efficiently. @@ -163,7 +163,7 @@ In typical usage, a vault is created by encumbering coins under a taptree [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki (BIP-341)] containing at least two leaves: one with an <code>OP_VAULT</code>-containing script that facilitates the expected withdrawal process, and another leaf with -<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered +<code>OP_VAULT_RECOVER</code> which ensures the coins can be recovered at any time prior to withdrawal finalization. The rules of <code>OP_VAULT</code> ensure the timelocked, interruptible @@ -172,7 +172,7 @@ withdrawal by allowing a spending transaction to replace the some parameters to be set at spend (trigger) time. All other leaves in the 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 +the <code>TAPLEAF_UPDATE_VERIFY</code> design that was proposed [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html in 2021]. These tapleaf replacement rules, described more precisely below, ensure a @@ -205,14 +205,14 @@ The vault has a number of stages, some of them optional: === Fee management === A primary consideration of this proposal is how fee management is handled. -Providing dynamic fee management is critical to the operation of a vault, since +Providing dynamic fee management is critical to the operation of a vault, since * precalculated fees are prone to making transactions unconfirmable in high fee environments, and * a fee wallet that is prespecified might be compromised or lost before use. But dynamic fee management can introduce [https://bitcoinops.org/en/topics/transaction-pinning/ pinning vectors]. Care -has been taken to avoid unnecessarily introducing these vectors when using the new +has been taken to avoid unnecessarily introducing these vectors when using the new destination-based spending policies that this proposal introduces. Originally, this proposal had a hard dependency on reformed transaction @@ -237,7 +237,7 @@ When evaluating <code>OP_VAULT</code> (<code>OP_SUCCESS187</code>, <leaf-update-script-body> <push-count> [ <push-count> leaf-update script data items ... ] -<trigger-vout-idx> +<trigger-vout-idx> <revault-vout-idx> <revault-amount> </source> @@ -413,10 +413,10 @@ that contains a taptree of the form <source> tr(<internal-pubkey>, leaves = { - recover: + recover: <recovery-sPK-hash> OP_VAULT_RECOVER, - trigger: + trigger: <trigger-auth-pubkey> OP_CHECKSIGVERIFY (i) <spend-delay> 2 $leaf-update-script-body OP_VAULT, (ii) @@ -434,7 +434,7 @@ Typically, the internal key for the vault taproot output will be specified so that it is controlled by the same descriptor as the recovery path, which facilitates another (though probably unused) means of recovering the vault output to the recovery path. This has the potential advantage of recovering the -coin without ever revealing it was a vault. +coin without ever revealing it was a vault. Otherwise, the internal key can be chosen to be an unspendable NUMS point to force execution of the taptree contents. @@ -442,7 +442,7 @@ force execution of the taptree contents. === Triggering a withdrawal === To make use of the vault, and spend it towards some output, we construct a spend -of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the +of the above <code>tr()</code> output that simply replaces the "trigger" leaf with the full leaf-update script (in this case, a timelocked CTV script): <source> @@ -461,17 +461,17 @@ Output scripts: [ tr(<internal-pubkey>, leaves = { - recover: + recover: <recovery-sPK-hash> OP_VAULT_RECOVER, <-- unchanged trigger: - <target-CTV-hash> <spend-delay> - OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the + <target-CTV-hash> <spend-delay> + OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKTEMPLATEVERIFY <-- changed per the leaf-update rules of OP_VAULT ... [ possibly other leaves ] } - ), + ), [ optional revault output with the same sPK as the original vault output ], @@ -499,7 +499,7 @@ entails trade-offs. ==== Unauthorized recovery ==== -Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>. +Unauthorized recovery simplifies vault use in that recovery never requires additional information aside from the location of the vault outpoints and the recovery path - the "authorization" is simply the reveal of the recovery path, i.e. the preimage of <code><recovery-sPK-hash></code>. But because this reveal is the only authorization necessary to spend the vault coins to recovery, the user must expect to recover all such vaults at once, since an observer can replay this recovery (provided they know the outpoints). @@ -513,7 +513,7 @@ These limitations are to avoid pinning attacks. ==== Authorized recovery ==== -With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required. +With authorized recovery, the user must keep track of an additional piece of information: how to solve the recovery authorization script fragment when recovery is required. If this key is lost, the user will be unable to initiate the recovery process for their coins. If an attacker obtains the recovery key, they may grief the user during the recovery process by constructing a low fee rate recovery transaction and broadcasting it (though they will not be able to pin because of the replaceability requirement on recovery transactions). @@ -521,7 +521,7 @@ However, authorized recovery configurations have significant benefits. Batched r ==== Recommendation: use a simple, offline recovery authorization key seed ==== -The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated. +The benefits of batching and fee management that authorized recovery provides are significant. If the recovery authorization key falls into the hands of an attacker, the outcome is not catastrophic, whereas if the user loses their recovery authorization key as well as their trigger key, the result is likely coin loss. Consequently, the author's recommendation is to use a simple seed for the recovery authorization key that can be written down offline and replicated. Note that the recovery authorization key '''is not''' the recovery path key, and this is '''much different''' than any recommendation on how to generate the @@ -542,7 +542,7 @@ the trigger authorization pubkeys. Note that when using unauthorized recovery, the reveal of the recovery scriptPubKey will allow any observer to initiate the recovery process for any vault with matching recovery params, provided they are able to locate -the vault outpoints. As a result, it is recommended to expect that +the vault outpoints. As a result, it is recommended to expect that '''all outputs sharing an identical unauthorized <code><recovery-sPK-hash></code> should be recovered together'''. This situation can be avoided with a comparable key management model by varying @@ -589,7 +589,7 @@ are essentially dependent on v3 transaction relay policy being deployed. <code>OP_VAULT</code> outputs with the same taptree, aside from slightly different trigger leaves, can be batched together in the same withdrawal -process. Two "trigger" leaves are compatible if they have the same +process. Two "trigger" leaves are compatible if they have the same <code>OP_VAULT</code> arguments. Note that this allows the trigger authorization -- the script prefixing the @@ -617,7 +617,7 @@ can be recovered into the same output. Recovery-incompatible vaults which have authorized recovery can be recovered in the same transaction, so long as each set (grouped by -<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows +<code><recovery-sPK-hash></code>) has an associated ''recoveryOut''. This allows unrelated recoveries to share common fee management. === Watchtowers === |