few fixups

Author: instagibbs

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