Liana is a wallet that lets you specify, in addition to the regular wallet key, a recovery key that can only be used after a configurable delay. Starting from this release you’ll be able to specify more than one key for both. It opens up new self or collaborative custody configurations, with a different set of tradeoffs than what’s available today.
The first, and maybe obvious, one is decaying multisig. Let’s say you are willing to self-custody the part of your company’s treasury that is in bitcoins. After consultation with your 2 business partners you are seriously considering a 2-of-3 multisig between the three of you. However you are still concerned by the risk of losing the coins, albeit reduced by the use of a threshold of 2 keys in the multisig.
If you are estimating the risk of at least 2 of you losing access to the key to be larger than the risk of you not having the chance of spending your coins in a year AND one of you being malicious (or compromised), then on Liana you would be able to set the possibility for your 2-of-3 multisig to degrade into a 1-of-3 multisig 1 year after receiving a coin.
Trust-distributed safety net
Another usecase is adding a less-trusted safety net to your self-custody setup. Let’s say you are new to Bitcoin, and started acquiring some coins on a custodial platform. You then got introduced to this friendly community of obnoxious bitcoiners insulting each other on social networks. One thing leading to another, your engagement farming started to need you to virtue signal about self-custodying your corn. But, behind your reckless Twitter avatar with laser eyes, you are intimately too scared about screwing up somewhere and losing everything in the process.
With Liana you can set the key of a service provider to become available, say, one year after you receive a coin. So you just use your wallet as normal, but if you lose access to your key and don’t move your coin for a year you still have the option of trusting the service provider for recovering your coins. As long as the timelock is active, you are never trusting the service provider.
But Liana permitted that from the start. With this new release you’ll even be able to configure a threshold of multiple service providers as your recovery solution. This way, your safety net becomes resistant to one (or more, depends on the threshold) of the service providers being malicious or simply unavailable by the time you need them.
Note how this can be combined with the decaying multisig, too. Instead of a 2-of-3 degrading in a 1-of-3, you could introduce external keys in the recovery path. For instance, the 2-of-3 between the three business partners could become after 1 year a 3-of-5 with two external service providers. This has the advantage of reducing the incentive for an attacker to obstruct the operations (to let the timelock trigger), at the cost of introducing some amount of trust in external companies.
Last usecase i’ll mention in this blog post (there are more though!) is the cosigner one. One may want to enforce a spending policy on a wallet, restricting all outgoing payments to match certain criterions (whitelisted addresses, amounts maxima, 2FA, ..). Although other solutions exist, this is typically achieved using a service provider that will co-sign all transactions (refusing to sign if the policy is breached).
But a problem quickly arises. Are you going to put your funds in a 2-of-2 multisig between you and the service provider? Probably not. Therefore what most of those services typically do is introducing an additional backup key that you hold, and make the Script a 2-of-3 multisig. This way you are sure they won’t rug-pull you, since you hold 2 keys yourself. But then can you be sure the policy can actually be enforced in case of any serious threat?
One way of fixing this is by using a timelocked recovery key. Or multiple. The key is not available for normal operations (again, assuming you’ll be able to access the wallet at least once every X months) and therefore there is no incentive to threaten the holder since they won’t be able to breach the policy. In the unlikely case the service provider disappears, you can always wait and use the timelocked recovery key.
Sure, you still trust the cosigner to actually enforce the policy. Making the backup key be timelocked does not change that. Vaults are a way to use a different trust model for instance. But they incur a significant burden unless we get some form of covenants on Bitcoin.
Side note: Blockstream Green (formerly Green wallet) is providing a 2FA service and has been a precursor of what we describe in this section. They don’t use Miniscript descriptors (yet) though, so it makes recovery more difficult.
Our technically inclined readers may be interested in the fact we only enable “legacy” multisigs.
n multisigs using
multi() in Miniscript). Bitcoin Script, and
the Miniscript framework, let us use more advanced multisigs. For instance you could ascribe weight
to some keys, or require that some of them always be used. With “legacy” multisig all
n keys have
a weight of
1 and any
k of them are enough to Spend. I think it’s fine for most usecase. If ever
a common usecase would require more advanced multisigs, it would be simple to enable (in fact the
daemon would already supports
But we opted for not introducing more complexity to the Graphical User Interface by default.
You can learn more about the changes from this release in our release notes. We might write a post or two about how we thought about various things there, from the complexity of coordinating the creation of the descriptor to how we are doing reproducible (and bootstrapable!) builds. But that’s a story for another time. :)
As usual, Liana is an Open Source project. Feedback and contributions of any form are very welcome!
If you are interested but don’t know where to start, you can check out the
CONTRIBUTING.md. If you have
any question feel free to open an issue or join the
chat at Libera on the
#revault channel (still :p).