Remove trailing whitespace from all BIPs

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