Sometimes the simplest method for accomplishing something is the best way. With many technologically impressive advances and concepts for protecting crypto funds from the litany of hacks that plague the industry, mainly exchanges, one that has recently resurfaced is a particularly clever idea.
Called “the vault,” the idea resurfaced from Bitcoin core developer Bryan Bishop, who revamped the proposed concept from 2016 for what is ostensibly a way to delay Bitcoin transactions before actually sending them.
The proposal comes at an important time in the crypto markets, as the ecosystem anxiously awaits the entrance of institutions, but many exchanges are still under threat from hackers.
Hackers are not just settling for smaller exchanges either. A recent, sophisticated attempt to subvert Coinbase’s security was fortunately foiled by the Coinbase security team.
Additionally, Binance underwent an extortion attempt for user KYC identity documents leaked online following their high-profile hack earlier in the year.
The security problem of exchanges is real and endemic, particularly centralized exchange models where vast sums of digital assets are stored. Grayscale even recently announced they were moving $2.7 billion of their assets under management (AUM) to Coinbase custody, highlighting just how much value is at stake in hacking attempts.
Despite all of the innovation in P2P, non-custodial exchanges, however, the vault may ultimately prove one of the most valuable weapons against exchange hacks, and it’s very straightforward.
What is The Vault?
The initial proposal was based on the concept of special Bitcoin addresses that had two private keys: a “vault” key and a “recovery” key. The recovery key would function within a time delay, so in effect, spending funds (i.e., BTC in cold storage) with the vault key would initiate the transaction, but not actually execute the transaction until a pre-determined window of time passes where the recovery key can halt the transaction.
For example, if Alice is a hacker who wants to steal Bob’s BTC from his cold storage wallet, she could socially engineer him into giving up the vault key. Alice would subsequently spend the vault key, which would initiate the transaction. However, Bob would be notified of the spend (i.e., via a watchtower), and have 24 hours to reclaim the funds to a special address — effectively preventing Alice from receiving the stolen BTC.
The original proposal was never adopted because it required a fork of the Bitcoin protocol that would’ve enabled quasi-reversible transactions in certain instances. And with Bitcoin’s conservative approach to major changes, that was a non-starter.
But the idea never died, especially amidst the backdrop of lucrative hacks and subsequent money laundering endeavors by malicious actors. Enter Bryan Bishop.
Bishop is a Bitcoin core contributor who re-introduced the concept of vault addresses with some slight tweaks in an email to the Bitcoin dev mailing list.
How it Works
Bishop proposes the use of 3 transactions for iterating through the various conditions of the vault setup process that would enable the vault concept to materialize without the need for a fork — a significant advantage. Bishop defines the vault as:
“Here, a vault is defined as a transaction setup scheme that binds both the user and the attacker to always using a public observation and delay period before a weakly-secured hot key is allowed to arbitrarily spend coins. This is the same definition previously used[1]. During the delay period, there is an opportunity to initiate recovery/clawback which can either trigger deeper cold storage parameters or at least reset the delay period to start over again for the same keys.”
The process is initiated via the “vault transaction” that locks the funds, only to be spent by a specific private key. Subsequently, the owner of the vault key can decide to enable a spend from the transaction via the “weakly-secured” wallet, which is a hot wallet.
The specific private key that can unlock the funds from the first transaction (in the hot wallet) is used in the second transaction, called the “delayed spend transaction” which can be spent in two ways:
- Spend by the owner, who actually intended to spend the bitcoins to the hot wallet following the pre-set time interval — such as 24 hours. In this setup, the owner of the vault key controls the private key to the hot wallet.
- Spend the coins immediately, which requires a different private key.
The different private key for an immediate spend creates the third transaction, which is known as “revaulting,” and sends the coins to a new address or another vault — such as clawing back the transaction to the original cold wallet should the initial spend be malicious.
Interestingly, following the use of the two private keys in the “delayed spend transaction” and “revaulting” phases, the keys are actually destroyed. According to Bishop:
“The delete-the-key trick is simple. The idea is to pre-sign at least one transaction and then delete the private key, thus locking in that course of action.”
That non-reversible course of action means that, at a high level, the entire vault sequence is an iterated cycle of connected spends (i.e., pre-signed transactions) where each transaction step can only be unlocked by the next phase. For example, the vault transaction (the first transaction) can only be unlocked with the “delayed spend transaction,” and the “delayed spend transaction” can only be unlocked with the time-locked hot wallet key after the specific period, or using the “revaulting” transaction to claw back a spend or send the bitcoins to a backup address.
Overall, the general series of transactions looks as follows:
To complete the process, the original vault transaction is broadcast to the Bitcoin network as an on-chain transaction, and the owner of the vault now has bitcoins linked to the vault address. The owner can spend his/her bitcoins by simply broadcasting the delayed spend transaction and waiting for the allotted period.
One of the drawbacks of the model, however, is that it is not compatible with multisig situations, and according to Bishop:
“Unfortunately, delete-the-key doesn’t really work for multisig scenarios because nobody would trust that anyone else in the scheme has actually deleted the secret. If they haven’t deleted the secret, then they have full unilateral control to sign anything in that branch of the transaction tree.”
Security Consequences
At the technical level, the idea of a vault may seem complex, but it is easiest just to think of it as optionality to clawback unwanted transactions should they be spent with malicious (or accidental) intent — using a time delay. A simple, yet powerful notion.
For example, vault transactions would drastically reduce hacker incentives if they know that exchanges are using the model for their cold storage bitcoins. One of the most alluring honeypot components of big stashes of bitcoins on exchanges is that, once they are broadcast to the network, there’s no reversing the transaction by the exchange.
With vault transactions, exchanges can simply dedicate team members to review all spent transactions within a specific time delay period, effectively mitigating the capacity of hackers to abscond with funds on short notice.
Add in the fact that a fork is not needed, and the vault appears like a win-win for the broader bitcoin ecosystem. The actual functionality used is already built into the Bitcoin code base, specifically, time-locked contracts, which are also fashioned for Bitcoin’s Lightning Network. Bishop still needs to complete the code for the vault, but without a contentious fork as part of the proposal, the barriers to its support are reduced significantly.
The dark history of cryptocurrency exchanges has caused headaches across the industry in a variety of forms. Vault may be the simple and elegant solution needed to end the endemic prevalence of exchange hacks in the market.
