Every bitcoin strategy needs a financial plan. Learn more at Sound Advisory
Several bitcoin wallets and custody services have begun exploring time-based security and recovery options. These offerings have piqued the interest of some bitcoin holders, who are curious to learn more about how they work, and ultimately determine if they are a good choice for protecting their bitcoin savings.
In this article, we will explain what these custody structures are designed to accomplish, and introduce the foundational technologies that have enabled them—namely timelocks and miniscript. We’ll take a look at some practical examples, and discuss the tradeoffs of these wallets, to help you make an informed decision about whether or not to use them.
The term “timelock wallet” in this article refers to a bitcoin wallet composed of addresses that use timelocks as part of their security model. Timelock wallets can be marketed using a variety of terminology, such as wallets offering “time-based recovery keys,” “time-delayed inheritance keys,” “advanced miniscript security,” or some other combination of similar words.
Timelocks introduce the element of time as a factor to determine the conditions necessary for spending bitcoin. A simple example would be an address built to prevent bitcoin from being spent out of it until a specified calendar date and time (or alternatively, until a certain block height is reached on the blockchain).
A more advanced example would be an address designed to have a default spending path, and another spending path that only becomes available after some time has elapsed. A structure like this could be helpful if the default path of accessing the bitcoin is no longer usable, due to keys becoming lost or destroyed. The owner of the bitcoin could then simply wait for the recovery path to be enabled, which might have more lenient spending requirements, or require entirely different private keys. Interest in this type of recovery mechanism is the primary catalyst that has driven the emergence of timelock wallet offerings in the bitcoin custody market.
Timelock wallets are built leveraging two main tools. First is the timelock function itself, which can have various approaches and limitations. Second is miniscript, a more recent development that provides a safer way to build complex spending conditions into bitcoin addresses, such as multiple spending paths. Next, we will take a closer look at these technologies.
There are two different functions for building a timelock into a bitcoin address. One function is CLTV (CheckLockTimeVerify). This tool introduces absolute locktime, meaning the timelock will expire at a designated time, regardless of when bitcoin is received into the address. This approach would pose a problem for wallets with lenient recovery paths guarded by timelocks, because as the set time draws near and passes, the security model of the wallet fundamentally changes. If you wanted new deposits to have a recovery path that is sufficiently in the future, you’d have to periodically migrate to an entirely new wallet (a new collection of addresses with a different wallet configuration) with a different absolute locktime.
The other function is CSV (CheckSequenceVerify), which establishes relative locktime. This refers to a timelock which is set for each UTXO relative to when it was received into the address. Therefore, each UTXO can have a different timelock expiration. This is the preferred approach for wallets with timelock-based recovery, because the security model of the wallet stays constant over time—reseting the countdown for a timelock can be achieved by transferring the bitcoin to a new address within the same wallet, rather than building and backing up an entirely different wallet.
A visual example contrasting an address using absolute locktime with an address using relative locktime. At creation, each locktime is set for 12 months. Absolute locktime ends at the same time for all deposits, while relative locktime has the same timelock duration for all deposits.
Another important difference between CLTV and CSV is the locktime constraints. CLTV could be used to lock bitcoin for several centuries, meaning any mistakes while setting the locktime could yield tragic results. Meanwhile, CSV has a maximum locktime of either 65,535 blocks (about 15 months) or 65,535 x 512 seconds (about 13 months). Since CSV is the choice of most timelock wallets, this limitation is quite relevant.
Bitcoin, by consensus, uses a simple stack-based programming language called Script to define the conditions under which bitcoin can be spent. However, Script has usability challenges for people interested in building more intricate spending conditions beyond the typical singlesig or multisig wallet. Composing, validating, and interpreting scripts with multiple conditional spending paths can be difficult to achieve securely and efficiently. This touches on the motivation for BIP379, which introduces miniscript.
Miniscript is a newer, optional language that represents scripts in a more useful way, enabling safer composition and analysis for more complex spending requirements. Although the current timelock wallet offerings were technically possible with Script alone, miniscript has paved the way for making them more practically feasible. The following is an example of Script, contrasted with an example of miniscript, which appears quite different and more condensed.
Script:
<A> OP_CHECKSIG OP_IFDUP OP_NOTIF
<B> OP_CHECKSIGVERIFY <50c300> OP_CHECKLOCKTIMEVERIFY
OP_ENDIF
Miniscript:
or_d(pk(A),and_v(v:pk(B),after(50000)))
Now that we’ve covered the basic premise of a timelock wallet and how they are constructed, we will examine a few ways that people have thought to use them. Although customizable, timelock wallets will generally have one main spending path (usually a multisig arrangement) and one recovery spending path guarded by the timelock. Ideas for recovery paths include decaying multisig, expanding multisig, and alternative keys.
Decaying multisig describes one method of creating a more lenient spending path for a multisig wallet after a timelock expires. Given a k-of-n multisig quorum, decaying multisig will reduce “k” so that fewer keys are needed to approve a withdrawal. For example, someone could build a wallet where bitcoin is controlled by a 3-of-3 multisig quorum that decays to a 2-of-3 multisig quorum when bitcoin hasn’t been moved for a period of time. This may prove useful if a key were lost.
Expanding multisig is another approach to building a timelocked recovery path. Given a k-of-n multisig quorum, expanding multisig will increase “n” so that there are additional keys capable of providing a valid signature to withdraw bitcoin. For example, someone could build a 2-of-2 multisig quorum that expands to a 2-of-3 multisig quorum for bitcoin that has been stagnant for a specified duration. If one of the original two keys were lost, the extra key could provide a renewed ability to access the bitcoin.
It’s also possible for a recovery path to differ more radically from the default spending path, utilizing completely different keys. For example, someone could have a 2-of-3 multisig quorum involving keys A, B and C as the default spending path, but after a timelock expires, the bitcoin could be accessed with a 2-of-3 quorum of keys D, E, and F. Alternatively, the recovery path could require just key D alone, or any other desired structure. This approach could play a role in an inheritance plan, where executors hold keys that are useless until the timelock expires.
At first glance, the recovery mechanisms available with timelock wallets can seem quite appealing. However, there are some significant tradeoffs to consider which might not be immediately evident.
For example, the ability to migrate a timelock wallet from one software to another is limited by very few adequate options, meaning that overall wallet recovery can be more challenging. Timelock wallet users can also experience substantially higher transaction fees, resulting from increased transaction data and pressure to move bitcoin at suboptimal fee rates. This pressure to periodically transfer bitcoin and reset timelocks could place you in stressful key management situations as well—you have to remember to move your bitcoin, or you lose security. Next we’ll cover these concerns in a bit more detail.
Ordinary singlesig and multisig wallets are ubiquitous within the bitcoin custody ecosystem. There are dozens of reputable wallet softwares that support these standardized wallet types in an interoperable manner, enabling users to easily migrate from one to another. This means that if your wallet software interface (where you can see and manage your bitcoin balance) were to have problems, you could simply import your wallet configuration information into an alternative interface to bypass those issues and access your bitcoin.
Meanwhile, timelock wallets have more complex wallet configurations—generally expressed as wallet descriptors—that include the miniscript details of the timelocks and various spending paths. At the time of writing, few wallet softwares have adopted the ability to import descriptors like this. If you build a timelock wallet within a certain software or collaborative service, and your account experiences issues, you could be stuck with very limited options for recovering the wallet. The options that do exist (such as Bitcoin Core) might be difficult for a nontechnical user to navigate.
If the adoption of descriptors and miniscript increases among reputable wallet softwares, the lack of wallet migration options may become less of a concern over time. On the other hand, there are additional challenges when importing a uniquely tailored miniscript wallet (such as a timelock wallet) in a sufficient way. Ideally, a wallet software should be able to understand an imported wallet’s design and show the relevant information to the user within the interface, such as the timelock status for each UTXO. This would require developers to build substantial enhancements for most of the popular wallet softwares available today, which currently aren’t designed to interpret and display such information.
One of the main variables that determines a bitcoin transaction fee is the amount of data the transaction uses. This transaction data contains basic information about the transfer, but it also must include the script describing the spending conditions that are being met, to ensure the transaction is valid. More complicated spending conditions will have larger scripts, and therefore they will tend to have more transaction data and higher fees.
A timelock wallet with multiple spending paths is an example of a structure that will tend to incur more transaction data than a typical bitcoin wallet. To investigate the difference, we compared a standard 2-of-3 multisig wallet with a couple of timelock wallets (all P2WSH). One timelock wallet was designed as a 2-of-2 quorum that expanded to a 2-of-3 quorum after 15 months, and we found that during a withdrawal from the wallet, each input (UTXO being spent) contributed about 13% more data (vB) than the standard multisig wallet. The second timelock wallet was a 3-of-3 quorum that decayed to a 2-of-3 quorum after 15 months. For this wallet, each input contributed about 38% more data.
While the difference in transaction data can vary depending on the specific details of a timelock wallet’s structure, it’s likely to have a material impact. It can be enough to affect UTXO management decisions, such as causing a higher recommended minimum UTXO size for the wallet. The additional transaction data also pairs very poorly with the increased need to conduct transactions, potentially at high fee rates, which will be covered in the next section.
A wallet with timelock-based recovery paths is intentionally built to have those spending paths disabled until a period of time has elapsed where the bitcoin hasn’t moved—as opposed to having the alternative paths available from the outset. The activation of recovery paths increases the accessibility of funds, which is helpful for dealing with the threat of lost keys, but it simultaneously decreases protection against the threat of theft. Therefore, a user of a timelock wallet seeks to keep the recovery paths perpetually guarded behind the timelocks, until they might actually be needed.
Toward the beginning of this article we mentioned that most timelock wallets use CSV, which has a maximum locktime of about 15 months. As a result, keeping the timelocks active requires resetting them at least once during every 15 month period. Resetting a CSV timelock is as simple as transferring the bitcoin to a new wallet address, but doing so will mean accessing the required private keys, pulling them out of their secure storage locations, and signing one or more transactions to move the entire wallet balance. Taking these sensitive actions under the pressure of time can open the door to stressful inconveniences and mistakes. Additionally, if the wallet is being operated with privacy in mind, even more frequent timelock reset transactions (treating every UTXO individually) might be needed to avoid undesired address combinations.
Another important consideration is the variance of transaction fee rates. Not only do transaction fees depend on transaction data as we covered in the previous section, but they are also determined by the fee rate environment—the global demand to move bitcoin quickly. Fee rate environments can fluctuate unpredictably across a wide range of values. If you set up a timelock wallet and plan to reset the timelocks every 14 months (one month before a 15 month expiration), you might find that in the final month, the fee rate environment is very high. You’d then be faced with some uncomfortable decisions: you could pay the extremely high transaction fee (potentially hundreds of times more expensive than when fee rates are low), or wait and hope fee rates decline. If you wait but fee rates continue to rise instead, you could feel backed into a corner, where you are forced to let your security deteriorate with the expiration of the timelocks, or lose a sizable portion of your bitcoin due to fees.
Timelock wallets leveraging miniscript are capable of introducing additional complexity into the security model for a bitcoin balance. They can be customized to achieve some neat structures, but they also come with several tradeoffs. Transaction fees, UTXO management, and external wallet migration all become more challenging for users to navigate. The pressure to take ongoing action differs from the custody strategy of many standard multisig wallet users, who want to simply lock down a long-term bitcoin treasury for years on end.
Timelocks tackle the threats of loss and theft in a unique way, frontloading extra protection from theft, which dissipates automatically over time to account for the possibility of lost keys. This creative intricacy is responsible for much of the appeal. However, standard multisig wallets are already widely recognized as robust solutions to the dual threats of loss and theft. Collaborative multisig wallets with backup keys held by key agents can function quite similarly to an expanding multisig timelock wallet, but with fewer concerns related to wallet migration or the specific timing of actions. Therefore, it’s not unreasonable to view timelock wallets as an unnecessary overcomplication.
If you are interested in learning more about how the various popular bitcoin custody options compare with each other, check out our general analysis, as well as our deep dive into institutional-grade custody. We invite you to ask questions about Unchained’s recommended bitcoin custody model and our suite of bitcoin-native financial services, by scheduling a free consultation call with our team.
.png)