Bitcoiners might be able to program long-term savings vaults into code, on-chain — an exciting development for Bitcoiners who keep the cryptocurrency as a long-term investment, known as ‘hodling’ (holding on for dear life).
Despite the roller coaster-like swings in bitcoin’s value, many people believe Bitcoin is a durable store of value. So, as the Bitcoin community increasingly seeks programmability regarding long-term investment practices, Bitcoin Core developers are now considering the addition of hard-coded “vaults” into Bitcoin’s software through a soft fork.
Bitcoin Core developer James O’Beirne proposed vault opcodes in a post to the official Bitcoin-Dev mailing list. His soft fork would add two new operation codes (“opcodes”) to Bitcoin script: OP_VAULT and OP_UNVAULT.
What would opcodes OP_VAULT and OP_UNVAULT accomplish?
If O’Beirne’s soft fork manages to gain consensus among Bitcoiners for activation — including Bitcoin miners and node operators accepting the soft fork — these operation codes will allow new forms of long-term safekeeping using Bitcoin script.
On-chain vaults could lock bitcoin up for a specified period, making it less likely that investors who prefer to hodl will panic when price plummets. Vault opcodes would add a suite of investing-related functions to programmable Bitcoin wallets, which would significantly enhance Bitcoin’s existing, rudimentary Timelock savings technology.
OP_VAULT would accept parameters that set a highly trusted spending path, a less trusted spending path, plus a timelock. The highly trusted spending path could involve a multi-signature requirement using devices in separate locations, making it easier to prevent an impulse purchase or the sale of bitcoin holdings in a moment of panic.
The less trusted spending path could include a hot wallet connected to the internet for convenience. A timelock would then prevent transactions from being confirmed into the hot wallet before a specified maturity time or block height.
OP_UNVAULT has three proposed parameters, including OP_VAULT’s same commitment to a highly trusted spending path and delay period. OP_UNVAULT also includes a commitment to outputs that a bitcoin holder wants to include in a future transaction.
These two new codes would enable a user to determine precisely when a transaction using specific outputs could be confirmed. OP_UNVAULT can detect an attempt to spend the funds held in the vault and send the transaction when the timelock has expired, if it matches rules previously set by the wallet’s owner. If the transaction does not meet those rules, it can send the funds to a highly trusted address to await input from the owner. This feature adds a security function to help prevent theft in case the less trusted wallet is compromised.
Today’s Bitcoin Core code already includes an option for pre-signed transactions.
Modern, alternative proposals to Bitcoin vault opcodes
Other proposed vault-like solutions include covenants, which could set a whitelist of approved scripts to which users could send transactions. Covenants, such as the CheckTemplateVerify proposal by Bitcoin Core developer Jeremy Rubin, would not involve O’Beirne’s proposed opcodes.
O’Beirne acknowledged that developers have long considered covenants, generally speaking, to be a critical component of vaults. However, he expressed dissatisfaction with the currently proposed covenant schemes. These schemes have failed to gain consensus among node operators and miners and include, in his view, bloated variables.
OP_VAULT and OP_UNVAULT could provide a solution with less witness data, saving on the amount of data transmitted over the Bitcoin network. They could also save on the number of steps required to spend bitcoin in a vault by eliminating the requirement to send it to a specific address before sending it to the desired address.
James O’Beirne’s proposal for vaults could provide a secure way to hard-code a hodling investment strategy. OP_VAULT and OP_UNVAULT could expand Bitcoin’s savings technology with only a couple new opcodes. The proposal’s activation still needs approval from other Bitcoin Core developers, safety audits, consensus among miners and node operators, and a successful soft fork launch.