What Policy does the Liana wallet use? Why would I use this Policy?

Question

I was looking at Wizardsardine's Liana wallet repo (beta software).

What is the Policy and associated Miniscript that is used by this wallet?

Why would I use this Policy? What is fixed and what is configurable by the user?

Does it support Taproot?

Answer 1

What is the Policy and associated Miniscript that is used by this wallet?

The Policy it uses is:

or(9@pk(primary),1@and(older(X),pk(recovery)))

To run it through sipa's Miniscript C++ compiler on his site you need to substitute X for a particular number for the timelock e.g. 12960 is approximately 90 days in number of blocks.

or(9@pk(primary),1@and(older(12960),pk(recovery)))

The resulting Miniscript from the C++ compiler is:

or_d(pk(primary),and_v(v:pkh(recovery),older(12960)))

The resulting Miniscript from the Rust compiler is the same (to be confirmed).

Why would I use this Policy?

In comparison to a 1-of-1 multisig this Policy gives you the extra protection of a recovery key in case you lose your primary key. In comparison to a 2-of-2 multisig or a 2-of-3 threshold this Policy is easier to spend from as you don't need to generate two signatures from two independent signers. In comparison to a 1-of-2 threshold this Policy prevents the recovery key being used until after the timelock in case the security around your recovery key isn't as strong as the security around your primary key.

What is fixed and what is configurable by the user?

The timelock can obviously be changed but this wallet isn't intended to support the user creating their own Policy. Apparently you can substitute multi keys instead of the single keys too (to be confirmed)

Does it support Taproot?

No. The use of Miniscript within a tr() descriptor is not yet spec'ed at the time of writing (February 20th 2023). There is some discussion on this gist for some of the proposed changes to Miniscript to do this.

Thanks to darosior for answering some of this on IRC.

This was also discussed with NVK on Twitter in May 2023. Essentially this Policy is only useful if you can detect that the backup key has been leaked. If you detect your backup key has leaked you have until the timelock expires to move your funds to a different address before the attacker can use your backup key. Without the timelock the attacker could use the backup key immediately once it was leaked.

If you can't detect that the backup key has been leaked (or don't regularly cycle through backup keys) then you'll end up in a race with the attacker to get a transaction confirmed onchain once the timelock expires.

Answer 2

At the moment Liana aims to accept any policy that describes:

1. A set of keys immediately available; or
2. A set of keys available only after a relative timelock; or optionally
3. Any number of additional sets of keys after increasing relative timelocks.

As of the 0.3 version only a single timelocked recovery path is supported. We plan to have multi-paths support in the upcoming 0.4 release.

The point is to introduce a "new dimension" to make tradeoffs when designing a policy: until now all of the existing wallets allowed users to configure "who" can have a say on a transaction. By tweaking the number of keys and the threshold necessary to spend, one could make various safety tradeoffs. Adding timelocks to the available options introduces a new class of such tradeoffs, and i would argue a particularly interesting one for many Bitcoin users ("when" a coin becomes spendable).

Let's illustrate this in two cases:

• A user of a single-key script, as long as they assume they would be able to move any of their coin within one year after receiving it, could have a safety net in case they lose their backups. Use Liana with a recovery key timelocked 1 year in the future held by a "safety net" service provider. This is purely additional safety for their coins: as long as they are able to move their coins within a year the service provider can never spend from under them, if they lose their backups and are unable to spend anymore they have the option to trust the service provider to recover them.
  Of course the recovery path can also be a threshold of various service providers, or a family member (à la uncle Jim).
• Decaying multisigs. Users of multisig very often have a lower threshold than the number of keys (2-out-of-3 or 3-out-of-5) to be resistant to the loss of one, or more, key(s). This of course also degrades the security of the setup. As long as you assume to be able to spend the coins regularly (and are willing to bear an additional delay in case of recovery), you could have the best of both worlds. Make the 3-of-5 into a 3-of-3 that degrades into a 3-of-4 after 9 months and into a 3-of-5 after 1 year.

Taproot is not yet supported. Liana makes use of Miniscript to safely use advanced scripts, and an effort to port Miniscript from P2WSH to Tapscript is underway. Liana will allow to use Taproot descriptors as soon as its current Bitcoin backend (a Bitcoin Core watchonly wallet) and signing devices support it.

There are also discussions regarding supporting absolute timelocks which would remove the need for having to rotate the coins and other annoyances, at the cost of having to occasionally create a new descriptor.