Back to blog list Back to blog list

Published on Wed, Dec 21, 2022 by Antoine Poinsot

Announcing Liana

Today we are releasing the first version of Liana, a simple self-custody solution that puts the emphasis on protecting against loss without degrading security.

Blog image cover

We’ve been working on Revault, an advanced (and admittedly, complex) self-custody solution targeted toward organizations with an emphasis on protecting against theft. Today we are releasing the first version of Liana, a simpler, lighter self-custody solution that puts the emphasis on protecting against loss without degrading security. Liana is a good fit for either individuals or organizations, small or big.

You can think of Liana as your regular Bitcoin wallet, with a plugged recovery mechanism. In a common Bitcoin wallet you receive coins on an address that corresponds to a single public key, yours. That is, a signature for your public key would allow you to spend the coins. For Liana it’s the same, but in addition a signature for a secondary key (the “recovery” key) would also let you spend the coins. But this recovery key is disabled until a configurable amount of time has passed since you received the coins.

For instance, let’s take primary and secondary keys 03ff45e710240a58dcd571208c5367c8aece1fc4eaffc2d869b39143fbd4e780e0 and 031bb3c76ef48e1266492a01f35be55870a8c7be85bbb286ac3169cd556f41953e. The spending policy for a common Bitcoin wallet would be:

  • Give me a signature for primary key 03ff45e710240a58dcd571208c5367c8aece1fc4eaffc2d869b39143fbd4e780e0

The spending policy on Liana would be either:

  • Give me a signature for primary key 03ff45e710240a58dcd571208c5367c8aece1fc4eaffc2d869b39143fbd4e780e0; or
  • Wait 1 year, then give me a signature for 031bb3c76ef48e1266492a01f35be55870a8c7be85bbb286ac3169cd556f41953e

This is a very simple tweak to how Bitcoin is currently used, yet it opens up a lot of interesting usecases. Inheritance is the obvious one. With today’s wallet how would you go about inheritance? You could hand a backup to your heir, but:

  1. You might not trust their capacity to securely keep a backup of your coins
  2. You might not trust them at all with the entirety of your holdings
  3. This is not actually solving the problem. It is just shifting it, since it’s equivalent to sending them the coins for that matter.

You could get fancy and involve trusted third parties (like a notary) in a multi-signatures scheme. But here also you necessarily introduce trust, as a combination of chosen parties need to be able to spend your coins without your agreement. Otherwise they wouldn’t be able to access it after you die. So you are trusting a certain legal system for not getting rug pulled at any time, pretty much like for your bank account. Maybe what is needed instead is a system based on a technical solution instead of trust.

What is needed is an electronic payment system based on cryptographic proof instead of trust

Enters Liana’s recovery key. It introduces another dimension to the inheritance scheme. In addition to who can spend the funds, you can now define when they gain access. This is a big deal since even though by definition for inheritance you want some other party to have access to your funds at some point, you may not want them to be able to spend the entirety of your holdings immediately. Hand the timelocked recovery key to your heir, use your wallet with the primary key as you would for any other wallet. When you get hit by a bus, your heir can recover all your coins 1 year after the fact.

In addition to inheritance, using a recovery key can be useful in single-party situations as well. It is well known that there is an inherent tradeoff between availability and security for a backup. That is, increasing the protection of your backups against theft is always going to come at the expense of a decreased availability of the backup. For instance, putting your backup in a bank’s safe deposit box is likely going to decrease the probability of theft, but you need to make sure the bank actually lets you access your backup when you absolutely need it for recovery. Assessing whether a compromise is worth it needs to be done within the context of someone’s specific threat model. But Liana brings a new dimension to what is possible today: control over when a backup becomes available. Typically you could afford a more secure backup of the primary key, and a more accessible one for the recovery key.

Of course it’s not a panacea. One additional thing to care about when using Liana is to not let timelocks expire, as you would fall back to the current situation where you trust your heir to not spend from under you. But at least timelocks make it possible to have a trustless inheritance scheme. And Liana is trying to make this new way of using Bitcoin as accessible as possible. We’d love to have feedback about this so feel free to open tickets for comments, bug reports or feature requests on our issue tracker.

At the moment Liana uses relative timelocks, that is the clock starts ticking when you receive the coins. For instance if you’ve configured a timelock of 1 year before the recovery spending path becomes available, you need to use this coin in a transaction within the year after you’ve received it so the recovery path never becomes available. In addition, since not all coins are received at the same time, they won’t become recoverable by the heir at the same date.

Another possibility would be for Liana to let you use absolute timelocks. Instead of configuring the expiration of the locktime as a period relative to when the coin was received, it is set at a fixed date in the future. For instance, instead of “1 year after reception the recovery path becomes available” you could have “on the 21st of December of year 2025, the recovery path becomes available”. Advantages of this approach include that you may use longer timelocks (may be useful for cold(er) wallets), and that the recovery path will become available at the same time for all your coins. The main drawback and the reason why we preferred relative timelocks as default is that you would then introduce a fixed expiration date for your wallet. Past (or shortly before) the configured absolute locktime date, you would have to create a new wallet with a later expiration date and sweep all the coins there.

The next release of Liana will also bring support for multisig. In addition to allow today’s users of multisig to plug a recovery path to their scheme, it would enable decaying multisigs when complemented with the “multi-paths” upgrade planned for the following version. For instance a 4-of-4 multisig that degrades into a 3-of-4 after 9 months and a 2-of-6 with specific recovery keys after a year and a half. This can also be used to introduce some kind of social recovery. If we enable absolute timelocks you could have for instance an advanced setup like a 3-of-3 between all your devices, that becomes a 2-of-3 after 1 year, and a 1-of-3 by January 2026 and finally by January 2030 any of your family members or notaries you would have involved would be able to spend unilaterally.

Finally, we intend to enable Taproot as soon as possible. Doing so would hide the recovery path on a simple Liana setup (with a single primary key, and one or more recovery keys) until it gets used. By integrating Musig2 in cooperation with signing devices developers, we could bring this obfuscation also to more advanced setups like decaying multisigs. We are actively working on adapting Miniscript to Tapscript to make this available as soon as possible.


Liana is bringing a simple way for bitcoiners to use a timelocked recovery, for inheritance or any other purpose. It will soon bring a new dimension to the tradeoffs when designing more advanced multi-signatures schemes. You could previously configure authentication (who hold the keys) and space (where are the keys). You’ll now be able to configure time (when do the keys become available).

Keep in mind this is a first, rather beta, version of Liana that we are releasing today. For instance you’ll quickly find out the UX was not prioritized for this first version. :) Now we went from 0 to 1, we will be able to iterate faster and to prioritize what actually matters for users: please give us feedback and suggestions on what features should be prioritizing moving forward. How would you use it?

Finally let me thank the Ledger (especially Salvatore Ingala) and Specter (Stepan Snigirev) developers for integrating Miniscript, thereby allowing us to empower users to take advantage of more features that Bitcoin provides without having to store their keys on their laptop directly.