We have developed a smart contract-based vault, where bitcoins locked inside can only be transferred after a user defined time delay.
Vaults
Key theft is one major issue plaguing bitcoin users. One way to safeguard bitcoins is to store them in a vault that disallows instant withdraw. To spend bitcoins in it, two sequential steps are needed.
- Issue a request to move coins out of the vault in a first transaction, called unvault.
- Wait for a predefined time (called the unvaulting period), say 24 hours after the first transaction is mined, before coins can be moved out in a subsequent transaction.
Both steps use a key called the vault key. Another key, called the recovery key, can have 24 hours to block the second transaction, in case the vault key is stolen. Typically, the vault key is stored in a hot wallet, while the recovery key in a cold wallet.
The first transaction signals that someone is attempting to transfer the coins and gives the owner a chance to block the second transaction that completes the transfer. Step 1 is akin to transferring money from a savings account to a checking account before spending it. Step 2 is like having 24 hours to revert an unauthorized payment made out of a checking account.
Implementation
Built upon relative timelock, we have developed the following vault contract.
At first, coins locked in the contract are unvaulted by calling unvault() at Line 18 in a transaction. It basically mutate a state unvaulted from false to true at Line 22 and propagate the state at Line 24–26. If everything goes well, coins can be withdrawn by calling withdraw() after the first transaction has been included in the blockchain for at least the unvaluting period, at Line 30. Line 35–37 use the relative timelock as before. If theft attempt is detected during that period, the recover key can undo the transaction and move the coins elsewhere at Line 41.
Discussion
We have developed a delayed-withdrawal vault.
- Compared to vaults offered by a trusted third party such as Coinbase, it is non-custodial. The user has to monitor the status of the vault UTXO to detect if there is any request transaction¹.
- It does not require any consensus change or new opcodes such as OP_CheckTemplateVerify in BIP 119 or OP_CheckOutputVerify in Bitcoin Covenants.
Additional measures can be added to make a vault even more secure, such as whitelists or spending limits. It is also straightforward to extend it to hold tokens.
[1] There are ways to do this without running a full node, such as real-time notifications in mAPI.
