<p>At the moment Liana aims to accept any policy that describes:</p>
<ol>
<li>A set of keys immediately available; or</li>
<li>A set of keys available only after a relative timelock; or <strong>optionally</strong></li>
<li>Any number of additional sets of keys after increasing relative timelocks.</li>
</ol>
<p>As of the <a href="https://github.com/wizardsardine/liana/releases/tag/0.3" rel="nofollow noreferrer"><code>0.3</code> version</a> only a single timelocked recovery path is supported. We plan to have <a href="https://github.com/wizardsardine/liana/issues/54" rel="nofollow noreferrer">multi-paths support</a> in the upcoming <code>0.4</code> release.</p>
<p>The point is to introduce a &quot;new dimension&quot; to make tradeoffs when designing a policy: until now all of the existing wallets allowed users to configure &quot;who&quot; 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 (&quot;when&quot; a coin becomes spendable).</p>
<p>Let's illustrate this in two cases:</p>
<ul>
<li>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 &quot;safety net&quot; 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.<br />
Of course the recovery path can also be a threshold of various service providers, or a family member (à la uncle Jim).</li>
<li>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.</li>
</ul>
<p>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.</p>
<p>There are also discussions regarding <a href="https://github.com/wizardsardine/liana/issues/48" rel="nofollow noreferrer">supporting absolute timelocks</a> 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.</p>

CC BY-SA 4.0
2023-03-22T18:10:50.743Z
2023-03-22T18:10:50.743Z
Antoine Poinsot
<blockquote>
<p>What is the Policy and associated Miniscript that is used by this wallet?</p>
</blockquote>
<p>The Policy it uses is:</p>
<p><code>or(9@pk(primary),1@and(older(X),pk(recovery)))</code></p>
<p>To run it through sipa's Miniscript C++ compiler on his <a href="https://bitcoin.sipa.be/miniscript/" rel="nofollow noreferrer">site</a> you need to substitute <code>X</code> for a particular number for the timelock e.g. <code>12960</code> is approximately 90 days in number of blocks.</p>
<p><code>or(9@pk(primary),1@and(older(12960),pk(recovery)))</code></p>
<p>The resulting Miniscript from the C++ compiler is:</p>
<p><code>or_d(pk(primary),and_v(v:pkh(recovery),older(12960)))</code></p>
<p>The resulting Miniscript from the Rust compiler is the same (to be confirmed).</p>
<blockquote>
<p>Why would I use this Policy?</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>What is fixed and what is configurable by the user?</p>
</blockquote>
<p>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)</p>
<blockquote>
<p>Does it support Taproot?</p>
</blockquote>
<p>No. The use of Miniscript within a <code>tr()</code> descriptor is not yet spec'ed at the time of writing (February 20th 2023). There is some discussion on this <a href="https://gist.github.com/sipa/06c5c844df155d4e5044c2c8cac9c05e" rel="nofollow noreferrer">gist</a> for some of the proposed changes to Miniscript to do this.</p>
<p>Thanks to darosior for answering some of this on IRC.</p>
<p>This was also <a href="https://twitter.com/nvk/status/1657355924283990017?s=20" rel="nofollow noreferrer">discussed</a> 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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-05-13T13:46:02.123Z
"this Policy is only useful if you can detect that the backup key has been leaked" -> I don't this this is correct. You seem to be talking about a very specific usage of Liana. It's useful to have a timelocked recovery key be held by a third party, or by yourself with different tradeoffs than the primary key. This type of policy is also useful for expanding / decaying multisigs. Could you clarify why you don't see this policy be useful outside of using it with a backup key you also own and can regularly check?
Antoine Poinsot
CC BY-SA 4.0
2023-05-13T13:48:43.117Z
"If you can't detect that the backup key has been leaked [..] then you'll end up in a race with the attacker" -> A trivial fix for this is to introduce another recovery path: after 1 year it's a 2of2 between my backup key and service provider X. After 1 year and 3 months it's me alone. If a thief gets their hand on your backup key you can just use the second recovery path and they (presumably) can't. If the service provider tries to rug-pull you there is always the last recovery path.
Antoine Poinsot
CC BY-SA 4.0
2023-05-13T14:50:25.453Z
@AntoinePoinsot: In the case that the backup key is leaked and you don't detect it the attacker will just wait for the timelock to expire and steal your funds (or you enter into a race with the attacker when you see the transaction being broadcast). This is assuming you aren't regularly rotating the backup key but I don't think you want to be doing that?
Michael Folkson
CC BY-SA 4.0
2023-02-20T14:15:23.130Z
2023-05-13T12:56:26.323Z
2023-05-13T12:56:26.323Z
Michael Folkson
<p>I was looking at Wizardsardine's Liana wallet <a href="https://github.com/wizardsardine/liana" rel="nofollow noreferrer">repo</a> (beta software).</p>
<p>What is the <a href="https://bitcoin.stackexchange.com/questions/91565/what-does-bitcoin-policy-language-offer-the-developer-that-miniscript-doesnt-w">Policy</a> and associated Miniscript that is used by this wallet?</p>
<p>Why would I use this Policy? What is fixed and what is configurable by the user?</p>
<p>Does it support Taproot?</p>

<wallet><script><taproot><miniscript>
What Policy does the Liana wallet use? Why would I use this Policy?
Michael Folkson
# What Policy does the Liana wallet use? Why would I use this Policy?

(Asked by: username_0 on 2023-02-20)

I was looking at Wizardsardine's Liana wallet [repo](https://github.com/wizardsardine/liana) (beta software).

What is the [Policy](https://bitcoin.stackexchange.com/questions/91565/what-does-bitcoin-policy-language-offer-the-developer-that-miniscript-doesnt-w) 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?

**Tags:** wallet, script, taproot, miniscript


---

## 2 answers

### Answer by username_1 on 2023-03-22. Score: 2 | Accepted answer

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](https://github.com/wizardsardine/liana/releases/tag/0.3) only a single timelocked recovery path is supported. We plan to have [multi-paths support](https://github.com/wizardsardine/liana/issues/54) 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](https://github.com/wizardsardine/liana/issues/48) 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.


---

### Answer by username_0 on 2023-02-20. Score: 2

> 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](https://bitcoin.sipa.be/miniscript/) 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](https://gist.github.com/sipa/06c5c844df155d4e5044c2c8cac9c05e) 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](https://twitter.com/nvk/status/1657355924283990017?s=20) 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.

> **Comments:**
> **username_1**: "this Policy is only useful if you can detect that the backup key has been leaked" -> I don't this this is correct. You seem to be talking about a very specific usage of Liana. It's useful to have a timelocked recovery key be held by a third party, or by yourself with different tradeoffs than the primary key. This type of policy is also useful for expanding / decaying multisigs. Could you clarify why you don't see this policy be useful outside of using it with a backup key you also own and can regularly check?  
> **username_1**: "If you can't detect that the backup key has been leaked [..] then you'll end up in a race with the attacker" -> A trivial fix for this is to introduce another recovery path: after 1 year it's a 2of2 between my backup key and service provider X. After 1 year and 3 months it's me alone. If a thief gets their hand on your backup key you can just use the second recovery path and they (presumably) can't. If the service provider tries to rug-pull you there is always the last recovery path.  
> **username_0**: @username_1: In the case that the backup key is leaked and you don't detect it the attacker will just wait for the timelock to expire and steal your funds (or you enter into a race with the attacker when you see the transaction being broadcast). This is assuming you aren't regularly rotating the backup key but I don't think you want to be doing that?  

---

