By Tom Honzik
Source: https://www.unchained.com/blog/examining-the-tradeoffs-of-miniscript-timelock-wallets
Various bitcoin wallet software and custodial services are beginning to explore time-based security models and recovery options. These products have piqued the interest of some bitcoin holders who want to understand how they work and determine if they are a good option for protecting their bitcoin savings.
In this article, we’ll explain the design goals of these custodians and introduce the foundational technologies that enable them—timelocks and Miniscript. We’ll look at some practical examples and discuss the trade-offs of these wallets to help you make an informed decision about whether to use them.
What is a "timelock wallet"?
In this article, the term "timelock wallet" refers to a Bitcoin wallet whose addresses use timelocks as part of their security model. Timelock wallets may be marketed using various terms, such as providing "experience-based recovery keys," "delayed key inheritance," "advanced Miniscript security," or some other similar combination.
Timelocks make time a factor in determining the necessary conditions for spending Bitcoin. A simple example is an address that inherently prevents Bitcoins from being spent before a certain calendar date or time (or perhaps preventing funds from being spent before a certain block height on the blockchain).
A more advanced example is an address designed with a default spending path but an alternate spending path that becomes available only after a certain period of time. This structure is useful when the default spending path becomes unusable, either due to lost keys or device damage. The owner of the address and its funds can simply wait for the alternate spending path to become available to retrieve the funds; this recovery path can be designed with more demanding spending requirements or require a completely different private key . Interest in this type of recovery mechanism has been a major catalyst for the emergence of time-locked wallets in the Bitcoin custody market.
How do timelock wallets work?
Timelock wallets are implemented using two primary tools. The first is the Bitcoin protocol's timelock functionality itself, which has different implementation methods and limitations. The second is Miniscript , a more advanced development tool that provides a more secure way to create complex spending conditions, such as multiple spending paths (these spending conditions are the predecessor of Bitcoin addresses). Let's take a closer look at these technologies.
Time lock function
There are two different ways to add a timelock to a Bitcoin address. One is "CLTV" (CheckLockTimeVerify), which creates an absolute timelock , meaning that the timelock expires (is unlocked) at a pre-specified time. The time at which bitcoins enter the address has no effect on the unlocking time of the timelock. This approach presents a problem for wallets using a loose recovery path with a timelock: as we approach or even pass the predetermined time, the wallet's security model completely changes. If you want new deposits to have a recovery path that's only valid far in the future, you'll have to periodically migrate to a completely new wallet (a new set of addresses with a different wallet configuration) just to use a different absolute timelock.
Another approach, "CSV (Check Sequence Verify)," establishes relative timelocks , meaning they count down from the moment each payment enters such an address. Consequently, each UTXO (in the wallet) has a different timelock expiration date. This is a better approach for wallets using time-based recovery mechanisms, as the wallet's security model remains constant over time—the countdown can be reset simply by transferring bitcoins (from an old address) to a new address in the same wallet, rather than having to construct and back up a completely new wallet.
- A visual example comparing an address using an absolute timelock and an address using a relative timelock. When creating the wallet, both timelocks are set to 12 months. In a wallet using an absolute timelock, timelocks in different addresses will expire at the same time; while relative timelocks will cause each deposit to have a separate countdown (just the same duration). -
Another key difference between CLTV and CSV is the range of lock times. CLTV can be used to lock Bitcoin for centuries, meaning anything can go wrong with the lock time, potentially with catastrophic consequences. However, CSV's maximum lock time is limited to either 65,535 blocks (approximately 15 months) or 65,535 * 512 seconds (approximately 13 months). Because CSV is the method used to lock wallets most of the time, this limitation is significant.
Miniscript
Bitcoin's consensus rules use a simple, stack-based programming language called " Script " to program the conditions under which a bitcoin can be spent. However, Script can be difficult to use for those interested in developing more complex spending conditions than those found in standard single- and multi-signature wallets. Combining, validating, and interpreting scripts that use multiple conditional spending paths can be difficult to implement securely and efficiently. This is the motivation for BIP379 Miniscript.
Miniscript uses a more useful way to express scripts, allowing more complex spending requirements to be more securely combined and analyzed. While current timelock wallets can technically be implemented using only Script, Miniscript paves the way for them to be more practical. Below is an example comparing Script and Miniscript code for the same spending condition. The resulting form is quite different, with the Miniscript code being more concise.
Script:
<A> OP_CHECKSIG OP_IFDUP OP_NOTIF <B> OP_CHECKSIGVERIFY <50c300> OP_CHECKLOCKTIMEVERIFYOP_ENDIFMiniscript:
or_d(pk(A),and_v(v:pk(B),after(50000)))(Translator's note: It should be noted that the introduction of Miniscript does not require changes to Bitcoin's consensus rules. In fact, Miniscript is only a subset of Script's expressive power. It simply uses a specific structure to use Script fragments, allowing us to combine, analyze, and verify code at the Miniscript level. In other words, it does not change Bitcoin itself (the actual expression of spending conditions is still Script code); it only changes the developer's programming environment.)
Time Lock Wallet Case
Now that we've covered the basic premise of timelock wallets and how they're constructed, let's look at some of the uses they've been envisioned for. While customizable, timelock wallets typically have a primary spend path (often a multi-signature mechanism) and a recovery spend path, bounded by a timelock. Recovery path ideas include decremental multi-signature, extended multi-signature, and replacement keys.
Decreasing multi-signature
Decreasing multi-sig is a method for creating a more permissive spending path for a multi-signature wallet that unlocks over time. Given a k-of-n multi-sig, decreasing multi-sig reduces "k" over time, requiring fewer keys to authorize withdrawals. For example, you could set up a wallet with Bitcoin controlled in a 3-of-3 multi-sig, but if the Bitcoin in the address hasn't moved for a while, you could reduce it to a 2-of-3 multi-sig. This could be useful in the event of a key loss.
Extended multi-signature
Extended multi-signature is another method for constructing a time-locked recovery path. Given a k-of-n multi-signature scheme, extended multi-signature gradually increases the value of "n" over time, allowing additional public keys to provide valid signatures to withdraw bitcoins. For example, you can set up a 2-of-2 multi-signature scheme, and then, after a period of inactivity, enable a 2-of-3 multi-signature scheme to withdraw bitcoins. If one of the original two keys is lost, the additional keys provide updated access to the bitcoins.
Alternative Key
The recovery path can be even more distinct from the default spending path—using completely different keys. For example, you could initially create a 2-of-3 multi-signature setup consisting of public keys A, B, and C, but after a timelock expires, you can spend funds using a multi-signature setup consisting of public keys D, E, and F. Furthermore, the recovery key could require only public key D, or any other structure you desire. This approach could be useful in estate planning—the executor's key wouldn't be useful until after the timelock expires.
Concerns about time-locked wallets
At first glance, enabling a recovery mechanism upon time lock expiration is very attractive. However, there are some trade-offs that may not be immediately apparent but are worth considering.
For example, migrating a timelock wallet from one software to another has very limited options, which means that wallet recovery may be more difficult overall. Users of timelock wallets may also face significantly higher transaction fees due to their larger transaction sizes and the increased likelihood of moving bitcoins under less favorable fee conditions. The pressure to regularly transfer bitcoins and refresh timelocks can lead to challenging key management situations—you must remember to move your bitcoins or your security will be compromised. We'll explore these concerns in more detail below.
Limited wallet migration options
Common single-signature and multi-signature wallets are ubiquitous in the Bitcoin custody ecosystem. Dozens of reputable wallet software programs support these standardized wallet types and are interoperable, making it easy for users to migrate from one program to another. This means that if your wallet software interface (the interface through which you view and manage your Bitcoin balance) experiences issues, you can simply import your wallet configuration information ( in Chinese ) into another interface to circumvent the issue and continue using your Bitcoin.
Meanwhile, timelock wallets have more complex wallet configuration information—typically expressed in a descriptor format—that contains Miniscript details about these timelocks and various spending paths. As of this writing, few wallet software have implemented the ability to import such descriptors. If you configure a timelock wallet in a particular software (or a collaborative service) and your account experiences a problem, you may have limited software options for restoring your wallet. While such options do exist (such as Bitcoin Core), they can be difficult for less technical users.
If descriptors and Miniscript are adopted by more reputable wallet software, the lack of migration options will become less of an issue over time. On the other hand, importing a unique, deeply customized Miniscript wallet (such as a timelock wallet) may present challenges. Ideally, a wallet software should be able to understand the design of an imported wallet and display useful information in its interface, such as the timelock status of each UTXO. This, in turn, would require developers to develop substantial enhancements to the vast majority of popular wallet software, as these software are not currently designed to interpret and display this information.
Higher transaction fees
One of the main variables that determines a Bitcoin transaction's fee is the size of the transaction's data. The transaction data contains basic information about the funds being transferred, but it also must include a script describing the spending conditions that must be met for the transaction to be valid. More complex spending conditions require larger scripts, and therefore tend to require more transaction data and higher fees.
Timelock wallets with multiple spend paths are one such example. To investigate the differences between multi-spend path devices and standard Bitcoin wallets, we compared a standard 2-of-3 multi-signature wallet with various timelock wallets (all using the P2WSH script type). One multi-timelock wallet was designed based on a 2-of-2 multi-signature architecture and expanded to a 2-of-3 multi-signature architecture 15 months later. We found that for each additional input (an additional UTXO spent) when withdrawing funds from the wallet, the transaction size (measured in vB) for the timelock wallet increased by 13% compared to a standard multi-signature wallet transaction. A second timelock wallet was designed based on a 3-of-3 multi-signature architecture and graduated to a 2-of-3 multi-signature architecture 15 months later. For this wallet, each additional input increased the data size by 38%.
The difference in transaction data is likely highly correlated with the specifics of timelock wallet construction (wallets utilizing taproot will benefit from this reduction in transaction data). This difference may be sufficient to influence a UTXO management decision, such as recommending a higher minimum denomination for a wallet's UTXOs . In addition to larger transaction volumes, timelock wallets may also have an increased need to initiate transactions in high-fee environments, another concern we'll discuss shortly.
Pressure to move Bitcoin regularly
Wallets with time-based recovery paths are intentionally designed so that these spending conditions are initially disabled and enabled only after the bitcoins in the address have been idle for a period of time—not to provide alternative paths available from the outset. While activating a recovery path increases accessibility to funds, which is very useful in dealing with the threat of lost keys, it also reduces protection against theft. Therefore, users of a time-locked wallet should ensure that the recovery path is always under the timelock until it is actually needed.
At the beginning of this article, we mentioned that the vast majority of timelock wallets use CSV, which has a maximum timelock of 15 months. Therefore, to ensure that the timelock does not expire, it must be reset at least every 15 months. Resetting a CSV timelock is not difficult; it simply involves transferring bitcoins to a new address within the same wallet. However, doing so requires accessing the required private keys, removing them from secure storage, and signing one or more transactions to move the entire wallet balance. Taking these sensitive actions under time pressure can be stressful and frustrating. Furthermore, if privacy is a concern, more frequent reset transactions (processing each UTXO separately) may be necessary to avoid address associations that could compromise privacy .
Another important consideration is the volatility of transaction fees. Transaction fees depend not only on transaction data (as discussed in the previous section), but also on the fee environment—the global demand for moving Bitcoin quickly. This fee environment can produce significant fluctuations during significant Bitcoin price fluctuations. If you set up a timelock wallet and schedule it to reset every 14 months (one month before the 15-month countdown), you might find that the fee rate is very high during this final month. This presents you with an uncomfortable choice: you can pay an additional, higher fee ( perhaps hundreds of times the lower fee rate ) or wait for the fee rate to decrease. If you wait and the fee rate continues to rise, you'll find yourself backed into a corner: either let the wallet's security degrade as the timelock expires, or you can fork out a significant amount of Bitcoin to cover the fee.
Conclusion: Are Timelock Wallets More Secure?
Timelock wallets leveraging Miniscript can add additional complexity to the security model for Bitcoin funds. They can be customized to implement some clever structures, but this comes with trade-offs. Transaction fees, UTXO management, and external wallet migration options can all be more challenging for users. The ongoing action model also differs from the custody strategy of many standard multi-signature wallet users, which directly lock up Bitcoin reserves for years.
Timelocks uniquely address the risk of key loss and theft, providing additional protection against theft by automatically releasing restrictions over time to mitigate the probability of key loss. This creative complexity is a primary source of their appeal. However, standard multi-signature wallets are already widely considered a robust solution to the risk of loss and theft. Using a jointly custodial multi-signature wallet with backup keys held by a key proxy provides functionality very similar to an extended multi-signature timelock wallet, but with fewer concerns about wallet migration and timely action. Therefore, there's some truth in viewing timelock wallets as unnecessarily complex.
(over)
