typos / gramma cleanup

1 files changed, 6 insertions, 6 deletions

diff --git a/bip-vaults.mediawiki b/bip-vaults.mediawiki
index 63aadfd..5a91447 100644
--- a/bip-vaults.mediawiki
+++ b/bip-vaults.mediawiki
@@ -27,7 +27,7 @@ the prespecified path.
 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 compromise is
+persistent threats. Users have little means to intervene once a compromise is
 detected. This proposal introduces a mechanism that significantly
 mitigates the worst-case outcome of key compromise: coin loss.
 
@@ -94,12 +94,12 @@ key. This approach was first demonstrated
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html in 2020].
 
 Unfortunately, this approach has a number of practical shortcomings:
-* generating and securely delete ephemeral keys, which are used to emulate the vault covenant, is required,
+* generating and securely deleting ephemeral keys, which are used to emulate the vault covenant, is required,
 * amounts and withdrawal patterns must be precommitted to,
 * there is a necessity to precommit to an address that the funds must pass through on their way to the final withdrawal target, which is likely only known at unvault time,
 * the particular fee management technique or wallet must be decided upon vault creation,
 * coin loss follows if a vault address is reused,
-* the transaction data that represents the "bearer asset" of the vault must be stored for perpetuity else value is lost, and
+* the transaction data that represents the "bearer asset" of the vault must be stored for perpetuity, otherwise value is lost, and
 * the vault creation ceremony must be performed each time a new balance is to be deposited.
 
 The deployment of a "precomputed" covenant mechanism like
@@ -157,7 +157,7 @@ The vault has a number of stages, some of them optional:
 
 * '''vault transaction''': encumbers some coins with an <code>OP_VAULT</code> script invocation.
 
-* '''trigger transaction''': spends one or more <code>OP_VAULT</code> inputs into an <code>OP_UNVAULT</code> output which carries forward the same recovery and delay parameters, along with a commitment to the proposed withdrawal target outputs. This publicly broadcasts the intent to withdrawal to some specific set of outputs. This transaction may have an additional output which allocates some of the vault balance into a partial revault, which simply encumbers the revaulted portion of the value into the same <code>scriptPubKey</code> of the originating <code>OP_VAULT</code> output(s).
+* '''trigger transaction''': spends one or more <code>OP_VAULT</code> inputs into an <code>OP_UNVAULT</code> output which carries forward the same recovery and delay parameters, along with a commitment to the proposed withdrawal target outputs. This publicly broadcasts the intent to withdraw to some specific set of outputs. This transaction may have an additional output which allocates some of the vault balance into a partial revault, which simply encumbers the revaulted portion of the value into the same <code>scriptPubKey</code> of the originating <code>OP_VAULT</code> output(s).
 
 * '''withdrawal transaction''': spends <code>OP_UNVAULT</code> trigger inputs into a compatible set of final withdrawal outputs per the target hash, after the trigger inputs have matured per the spend delay. The only authorization for this spend (aside from the relative timelock) is the content hash of the withdrawal outputs.
 
@@ -224,7 +224,7 @@ An arbitrary set of target withdrawal outputs that is specified as a parameter t
 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 
 
-* precalculated fees are prone to making transactions unconfirmable by high fee environments, and
+* 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
@@ -416,7 +416,7 @@ def find_revault_for_vault(vault_in) -> int:
     return None
 </source>
 
-=== <code>OP_UNVAULT</code> evaulation ===
+=== <code>OP_UNVAULT</code> evaluation ===
 
 ==== Witness program ====