Skip to content

Commit 24241ee

Browse files
authored
typos / gramma cleanup
1 parent 6ff8efd commit 24241ee

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

bip-vaults.mediawiki

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ the prespecified path.
2727
The hazard of custodying Bitcoin is well known. Users of Bitcoin must go to
2828
significant effort to secure their private keys, and hope that once provisioned
2929
their custody system does not yield to any number of evolving and
30-
persistent threats. Users have little means to intervene once compromise is
30+
persistent threats. Users have little means to intervene once a compromise is
3131
detected. This proposal introduces a mechanism that significantly
3232
mitigates the worst-case outcome of key compromise: coin loss.
3333

@@ -94,12 +94,12 @@ key. This approach was first demonstrated
9494
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html in 2020].
9595

9696
Unfortunately, this approach has a number of practical shortcomings:
97-
* generating and securely delete ephemeral keys, which are used to emulate the vault covenant, is required,
97+
* generating and securely deleting ephemeral keys, which are used to emulate the vault covenant, is required,
9898
* amounts and withdrawal patterns must be precommitted to,
9999
* 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,
100100
* the particular fee management technique or wallet must be decided upon vault creation,
101101
* coin loss follows if a vault address is reused,
102-
* the transaction data that represents the "bearer asset" of the vault must be stored for perpetuity else value is lost, and
102+
* the transaction data that represents the "bearer asset" of the vault must be stored for perpetuity, otherwise value is lost, and
103103
* the vault creation ceremony must be performed each time a new balance is to be deposited.
104104
105105
The deployment of a "precomputed" covenant mechanism like
@@ -157,7 +157,7 @@ The vault has a number of stages, some of them optional:
157157

158158
* '''vault transaction''': encumbers some coins with an <code>OP_VAULT</code> script invocation.
159159
160-
* '''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).
160+
* '''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).
161161
162162
* '''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.
163163
@@ -224,7 +224,7 @@ An arbitrary set of target withdrawal outputs that is specified as a parameter t
224224
A primary consideration of this proposal is how fee management is handled.
225225
Providing dynamic fee management is critical to the operation of a vault, since
226226

227-
* precalculated fees are prone to making transactions unconfirmable by high fee environments, and
227+
* precalculated fees are prone to making transactions unconfirmable in high fee environments, and
228228
* a fee wallet that is prespecified might be compromised or lost before use.
229229
230230
But dynamic fee management can introduce
@@ -416,7 +416,7 @@ def find_revault_for_vault(vault_in) -> int:
416416
return None
417417
</source>
418418

419-
=== <code>OP_UNVAULT</code> evaulation ===
419+
=== <code>OP_UNVAULT</code> evaluation ===
420420

421421
==== Witness program ====
422422

0 commit comments

Comments
 (0)