That is the fourth article in a sequence deep diving into particular person covenant proposals which have reached some extent of maturity meriting an in-depth breakdown.
OP_VAULT, put ahead by James O’Beirne in BIP 345 (with Greg Sanders added later as a co-author), is a covenant designed to implement vaults. It relies upon moreover on CTV (or TXHASH or different related opcodes) to finish the development of a vault.
Earlier than entering into how the proposal itself works, let’s have a look at what a vault is making an attempt to perform.
The aim of a vault is to enhance the safety of your bitcoin storage. That is completed by the introduction of a delay interval throughout any try to spend from the vault. Relatively than with the ability to instantly ship your bitcoin from the vault, the vault restricts them in order that they’ll solely be despatched to a “center floor” handle. Whereas cash being withdrawn from the vault are on this center floor state, they are often spent at any time right into a deep chilly storage pockets below your management (ideally a geographically distributed vault multisig), and solely to that deep chilly storage. After a pre-defined timelock the cash can then be spent onwards to the final word meant vacation spot.
That is one thing that’s doable to do presently with pre-signed transactions, however that brings a big diploma of complexity, inefficiency, lack of flexibility, and danger of shedding funds.
Utilizing pre-signed transactions requires you to resolve forward of time how a lot cash might be withdrawn at a time, what feerate the transactions withdrawing from the vault can pay, what the interim handle earlier than totally withdrawing is, and then you definitely have to securely delete the non-public keys used to pre-sign all these transactions.
A giant downside with this structure, except for the general restrictions of pre-decided quantities, charges, and many others., is that handle reuse isn’t protected. In a pre-signed transaction vault scheme, deposits are despatched to the handle used to pre-sign the preliminary vault transaction, and that together with all the opposite keys concerned are deleted after signing the vault transactions. Deal with reuse is dangerous follow, however you can not cease another person from sending funds to an handle they’ve used earlier than. Any such later deposited funds could be endlessly misplaced, because the vault keys have all been deleted.
As properly, each deposit right into a vault necessitates a contemporary arrange of latest keys, conducting the pre-signing ceremony yet again for the brand new set of transactions, guaranteeing the brand new set of keys are securely deleted, and managing the correct storage of all this info together with redundant backups. Each single deposit creates a chance for one thing to get tousled throughout the vault arrange, each deposit presents an opportunity for somebody who has compromised a system or gadget because the final deposit to attempt to steal your funds.
Pre-signed transaction vaults are a cumbersome and complex building, and current sufficient complexity that every use does current a non-negligible danger of messing up in a method that leads to misplaced funds.
Enhancements could be made with CTV, comparable to eliminating the necessity to securely delete keys, however the remainder of the complexity and danger nonetheless stays. Quantities and charges should nonetheless be pre-defined. Deal with reuse can nonetheless result in fund loss.
How OP_VAULT Works
OP_VAULT is constructed on Taproot, which means your complete design makes use of tapscript and is determined by the existence of taptrees and the script spending path. It additionally is determined by the usage of CTV (or TXHASH/related performance) to assemble a full vault.
The proposal is definitely two opcodes, OP_VAULT, and OP_VAULT_RECOVER. OP_VAULT is used to set off withdrawals from the vault, and OP_VAULT_RECOVER is used to brush triggered withdrawals into the deep restoration pockets. The thought is to assemble a taptree that has OP_VAULT paths in it for withdrawals, and UP_VAULT_RECOVER paths for sweeping any funds mid-withdrawal to a safe chilly pockets. This taptree is your vault.
OP_VAULT works by limiting how the outputs of a transaction spending an OP_VAULT encumbered coin should look. The opcode expects within the witness:
- A tapleaf script physique
- The variety of knowledge items for a script replace
- An output index for the withdrawal
- An output index for any funds going again into the vault
- An quantity of satoshis going again into the vault
OP_VAULT ensures that the right amount of funds despatched again to the vault is appropriate, and that the output script of that output is an identical to the taptree being spent from. It additionally takes the tapleaf script physique, and the info variables offered, and combines them right into a full tapleaf script. It then ensures that the output specified for withdrawal has an an identical script with the taptree of the enter being spent, besides the tapleaf being spent from is changed with the tapleaf script put along with knowledge from the witness.
This final trick is feasible as a result of with the intention to confirm the tapleaf is a part of the taptree within the first place the inside nodes of the merkle tree must be current to confirm. Hashing the brand new script with the identified inside leaves of the remainder of the tree ensures that solely that leaf of the tree was modified. The template for the script that dynamically be crammed in is outlined on the time of vault creation. For a typical vault use-case the script template would merely be a timelocked CTV spend path with the hash offered when triggering a withdrawal.
OP_VAULT_RECOVER is way less complicated. It takes a hash of the restoration script, and an output index for the restoration transaction. That output should include a script that precisely matches the predefined hash, and the whole lot of the quantity of funds within the enter being recovered should go to that output.
Each of those scripts could be “gated” with an authorization script, i.e. offering a signature from a selected key with the intention to set off a withdrawal or provoke a restoration. This has some commerce offs. For those who lose a restoration authorization key, you may now not set off a restoration transaction within the occasion of a theft of your withdrawal set off key. It does nonetheless, help you provoke a restoration from a number of vault UTXOs in the identical transaction because of specifying every enter’s corresponding outputs manually.
What Is OP_VAULT Good For
Clearly vaults. OP_VAULT cleanly addresses all the foremost limitations of a pre-signed transaction or CTV primarily based vault. No restrictive pre-decided denominations or pre-decided charges, no hazard in reusing addresses, and no necessity to take care of a excessive safety subject like key deletion each single time you deposit.
It’s much more versatile than simply vaults although. That was the meant use case when it was designed, however it’s a rather more basic covenant guaranteeing {that a} taptree truly carries ahead to the subsequent UTXO whenever you need it to, with pre-defined exit circumstances which have a point of flexibility.
You can also make one thing very near a Drivechain with OP_VAULT. Create a vault template that has an extremely lengthy timelock, on the order of 3-6 months (much like Drivechain withdrawals). Don’t have any authorization gate for any script and make the template public. Folks can now merely deposit funds into the “drivechain” by sending cash to that vault script. Anybody can suggest a withdrawal by merely spending from an OP_VAULT path and together with a CTV hash of their withdrawal transaction. Miners can implement this by merely refusing to mine any invalid withdrawal transactions, and if a malicious miner ever mined a malicious withdrawal set off, the subsequent trustworthy miner might merely revault the funds.
That’s what could be accomplished simply utilizing an an identical script template as really helpful within the BIP. The script template set for withdrawals is bigoted, and as such is doubtlessly very basic when it comes to what sorts of perpetuating self contracts OP_VAULT might allow.
Closing Ideas
OP_VAULT clearly accomplishes the objective of enabling correct vaults that don’t include the restrictions, complexities, and danger that pre-signed transaction vaults (and even less complicated covenant vaults with one thing like CTV) include. Nevertheless, in doing so it wound up introducing a reasonably vast and generalized set of functionalities to perform that unique objective.
The proposal would definitively allow a comparatively easy and safe vault performance, however it additionally opens up many different doorways. Drivechains are one thing that include a big diploma of danger centered round Miner Extractible Worth (MEV). The downsides of enabling such performance, and the inducement points and penalties it might have, needs to be weighed in opposition to the upside of enabling a properly constructed vault.
OP_VAULT is a comparatively mature proposal, however the diploma of performance that it permits shouldn’t be approached flippantly.