Bitcoin Magazine
Bitcoin Covenants: OP_VAULT (BIP 345)
This is the fourth article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in-depth breakdown.
OP_VAULT, put forward by James O’Beirne in BIP 345 (with Greg Sanders added later as a co-author), is a covenant designed to implement vaults. It depends additionally on CTV (or TXHASH or other similar opcodes) to complete the construction of a vault.
Before getting into how the proposal itself works, let’s look at what a vault is trying to accomplish.
The purpose of a vault is to improve the security of your bitcoin storage. This is accomplished by the introduction of a delay period during any attempt to spend from the vault. Rather than being able to directly send your bitcoin from the vault, the vault restricts them so that they can only be sent to a “middle ground” address. While coins being withdrawn from the vault are in this middle ground state, they can be spent at any time into a deep cold storage wallet under your control (ideally a geographically distributed vault multisig), and only to that deep cold storage. After a pre-defined timelock the coins can then be spent onwards to the ultimate intended destination.
This is something that is possible to do currently with pre-signed transactions, but that brings a large degree of complexity, inefficiency, lack of flexibility, and risk of losing funds.
Using pre-signed transactions requires you to decide ahead of time how much money will be withdrawn at a time, what feerate the transactions withdrawing from the vault will pay, what the interim address before fully withdrawing is, and then you have to securely delete the private keys used to pre-sign all these transactions.
A big problem with this architecture, aside from the overall restrictions of pre-decided amounts, fees, etc., is that address reuse is not safe. In a pre-signed transaction vault scheme, deposits are sent to the address used to pre-sign the initial vault transaction, and that along with all the other keys involved are deleted after signing the vault transactions. Address reuse is bad practice, but you cannot stop someone else from sending funds to an address they have used before. Any such later deposited funds would be forever lost, as the vault keys have all been deleted.
As well, every deposit into a vault necessitates a fresh set up of new keys, conducting the pre-signing ceremony all over again for the new set of transactions, ensuring the new set of keys are securely deleted, and managing the proper storage of all this information including redundant backups. Every single deposit creates an opportunity for something to get messed up during the vault set up, every deposit offers a chance for someone who has compromised a system or device since the last deposit to try to steal your funds.
Pre-signed transaction vaults are a cumbersome and complicated construction, and present enough complexity that each use does present a non-negligible risk of messing up in a way that results in lost funds.
Improvements can be made with CTV, such as doing away with the need to securely delete keys, but the rest of the complexity and risk still remains. Amounts and fees must still be pre-defined. Address reuse can still lead to fund loss.
How OP_VAULT Works
OP_VAULT is built on Taproot, meaning the entire design uses tapscript and depends on the existence of taptrees and the script spending path. It also depends on the use of CTV (or TXHASH/similar functionality) to construct a full vault.
The proposal is actually two opcodes, OP_VAULT, and OP_VAULT_RECOVER. OP_VAULT is used to trigger withdrawals from the vault, and OP_VAULT_RECOVER is used to sweep triggered withdrawals into the deep recovery wallet. The idea is to construct a taptree that has OP_VAULT paths in it for withdrawals, and UP_VAULT_RECOVER paths for sweeping any funds mid-withdrawal to a secure cold wallet. This taptree is your vault.
OP_VAULT works by restricting how the outputs of a transaction spending an OP_VAULT encumbered coin must look. The opcode expects in the witness:
- A tapleaf script body
- The number of data pieces for a script update
- An output index for the withdrawal
- An output index for any funds going back into the vault
- An amount of satoshis going back into the vault
OP_VAULT ensures that the correct amount of funds sent back to the vault is correct, and that the output script of that output is identical to the taptree being spent from. It also takes the tapleaf script body, and the data variables provided, and combines them into a full tapleaf script. It then ensures that the output specified for withdrawal has an identical script with the taptree of the input being spent, except the tapleaf being spent from is replaced with the tapleaf script put together with data from the witness.
This last trick is possible because in order to verify the tapleaf is part of the taptree in the first place the interior nodes of the merkle tree have to be present to verify. Hashing the new script with the known interior leaves of the rest of the tree ensures that only that leaf of the tree was changed. The template for the script that dynamically be filled in is defined at the time of vault creation. For a typical vault use-case the script template would simply be a timelocked CTV spend path with the hash provided when triggering a withdrawal.
OP_VAULT_RECOVER is much simpler. It takes a hash of the recovery script, and an output index for the recovery transaction. That output must contain a script that exactly matches the predefined hash, and the entirety of the amount of funds in the input being recovered must go to that output.
Both of these scripts can be “gated” with an authorization script, i.e. providing a signature from a specific key in order to trigger a withdrawal or initiate a recovery. This has some trade offs. If you lose a recovery authorization key, you can no longer trigger a recovery transaction in the event of a theft of your withdrawal trigger key. It does however, allow you to initiate a recovery from multiple vault UTXOs in the same transaction due to specifying each input’s corresponding outputs manually.
What Is OP_VAULT Good For
Obviously vaults. OP_VAULT cleanly addressed all the major limitations of a pre-signed transaction or CTV based vault. No restrictive pre-decided denominations or pre-decided fees, no danger in reusing addresses, and no necessity to deal with a high security issue like key deletion every single time you deposit.
It is a lot more flexible than just vaults though. That was the intended use case when it was designed, but it is a much more general covenant guaranteeing that a taptree actually carries forward to the next UTXO when you want it to, with pre-defined exit conditions that have some degree of flexibility.
You can make something very close to a Drivechain with OP_VAULT. Create a vault template that has an incredibly long timelock, on the order of 3-6 months (similar to Drivechain withdrawals). Have no authorization gate for any script and make the template public. People can now simply deposit funds into the “drivechain” by sending money to that vault script. Anyone can propose a withdrawal by simply spending from an OP_VAULT path and including a CTV hash of their withdrawal transaction. Miners can enforce this by simply refusing to mine any invalid withdrawal transactions, and if a malicious miner ever mined a malicious withdrawal trigger, the next honest miner could simply revault the funds.
That is what can be done just using an identical script template as recommended in the BIP. The script template set for withdrawals is arbitrary, and as such is potentially very general in terms of what types of perpetuating self contracts OP_VAULT could enable.
Closing Thoughts
OP_VAULT clearly accomplishes the goal of enabling proper vaults that do not come with the restrictions, complexities, and risk that pre-signed transaction vaults (or even simpler covenant vaults with something like CTV) come with. However, in doing so it wound up introducing a rather wide and generalized set of functionalities to accomplish that original goal.
The proposal would definitively enable a relatively smooth and secure vault functionality, but it also opens up many other doors. Drivechains are something that come with a large degree of risk centered around Miner Extractible Value (MEV). The downsides of enabling such functionality, and the incentive issues and consequences it could have, should be weighed against the upside of enabling a well constructed vault.
OP_VAULT is a relatively mature proposal, but the degree of functionality that it enables shouldn’t be approached lightly.
This post Bitcoin Covenants: OP_VAULT (BIP 345) first appeared on Bitcoin Magazine and is written by Shinobi.
Bitcoin Magazine
Bitcoin Covenants: OP_VAULT (BIP 345)
The fourth article in the Covenant series, examining the OP_VAULT proposal from James O’Beirne and Greg Sanders.
This post Bitcoin Covenants: OP_VAULT (BIP 345) first appeared on Bitcoin Magazine and is written by Shinobi. GLOSSARY, FEATURED, TECHNICAL, BIP 345, James O’Beirne, OP_VAULT, Vaults Bitcoin Magazine
