You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-vaults.mediawiki
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ the prespecified path.
27
27
The hazard of custodying Bitcoin is well known. Users of Bitcoin must go to
28
28
significant effort to secure their private keys, and hope that once provisioned
29
29
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
31
31
detected. This proposal introduces a mechanism that significantly
32
32
mitigates the worst-case outcome of key compromise: coin loss.
33
33
@@ -94,12 +94,12 @@ key. This approach was first demonstrated
94
94
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html in 2020].
95
95
96
96
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,
98
98
* amounts and withdrawal patterns must be precommitted to,
99
99
* 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,
100
100
* the particular fee management technique or wallet must be decided upon vault creation,
101
101
* 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
103
103
* the vault creation ceremony must be performed each time a new balance is to be deposited.
104
104
105
105
The deployment of a "precomputed" covenant mechanism like
@@ -157,7 +157,7 @@ The vault has a number of stages, some of them optional:
157
157
158
158
* '''vault transaction''': encumbers some coins with an <code>OP_VAULT</code> script invocation.
159
159
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).
161
161
162
162
* '''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.
163
163
@@ -224,7 +224,7 @@ An arbitrary set of target withdrawal outputs that is specified as a parameter t
224
224
A primary consideration of this proposal is how fee management is handled.
225
225
Providing dynamic fee management is critical to the operation of a vault, since
226
226
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
228
228
* a fee wallet that is prespecified might be compromised or lost before use.
0 commit comments