Liana (I): MiniScript Applied to Recovery and Inheritance
TL;DR: Liana allows you to define programmable spending paths using MiniScript + timelocks, so your bitcoin can have rescue, emergency, and inheritance plans without compromising daily usability. In this post we’ll see how to build policies like “if I don’t spend in 12 months, X inherits” or “emergency 1-of-1 path with delay” —and how to maintain a UX that doesn’t drive you crazy.
Connection With What We Saw Before
In the Nunchuk post we explored how a collaborative wallet manages roles (Key-User, Key-Backup, Key-Agent) and basic timelock policies.
Liana takes that logic further: it defines multiple spending routes, each with time-based conditions, so the wallet “decides” which path to use depending on inactivity.
Additionally, version v13.0 adds features like encrypted descriptor backup, xpub validations, and UI improvements that make experimenting with advanced policies safer and more convenient.
Liana takes that logic further: it defines multiple spending routes, each with time-based conditions, so the wallet “decides” which path to use depending on inactivity.
Additionally, version v13.0 adds features like encrypted descriptor backup, xpub validations, and UI improvements that make experimenting with advanced policies safer and more convenient.
Core Idea: Programmable Policies With Timed Routes
-
In Liana, you don’t just have “main spend vs recovery”; you can have several recovery routes with different timelocks.
-
Examples:
- Primary:
pk(A)— instant spend with your own key. - Inheritance:
and( after(12m), pk(Beneficiary) )— if you don’t touch the wallet for 12 months. - Emergency:
and( after(3m), pk(Agent) )— faster rescue path for urgent cases. - Deep backup:
and( after(24m), pk(DeepBackup) )— last resort.
- Primary:
-
Liana internally translates these routes into MiniScript/descriptor, integrates validations, and manages them for you (expiry alerts, renewal).
How to Model These Policies Without Breaking Daily UX
| Risk | What to Do | Practical Example |
|---|---|---|
| Too many routes = confusion | Limit to 2 or 3 routes max | Primary + inheritance + emergency |
| Timelocks too short | Add margin (at least 3–12 months) | Don’t set 7 days —you could trigger routes by mistake |
| Automatic renewal | “Refresh” UTXOs before route expiry | Make a “self-send” before the deadline |
| Early validations | Verify xpub/network when setting routes | Liana v13 already includes UI validations to avoid network errors |
Concrete Example in MiniScript / Descriptor
or(
pk(A),
or(
and_v(v:after(12m), pk(Beneficiary)),
and_v(v:after(3m), pk(Agent))
)
)
Interpretation of the Example
- Route 1 (short): Key A can always spend.
- Route 2 (inheritance): if there’s no activity for 12 months, B can spend.
- Route 3 (emergency): after 3 months, the agent can step in.
Risks and Limits to Mention
- Each UTXO must be “refreshed” to extend its timelock, which implies periodic transactions.
- In high-fee environments, refreshing can be costly, especially with many UTXOs.
- If you configure routes with overlaps or conflicts, you may end up with states where no route can be used.
- If you lose your descriptor or don’t have an encrypted backup, restoring becomes complex.
Useful Resources for Liana
- Official repo (docs + changelog): github.com/wizardsardine/liana
- Changelog v13 (UI improvements + encrypted descriptor): releases page
- Practical guide with BitBox02: BitBox blog
Closing
- Action today: use Liana on testnet and create a policy with at least two routes (primary + inheritance). Watch how it alerts you as expiry approaches.
- Question for readers: What recovery (emergency) route would you implement: 3 months, 6 months, 1 year? Why?
In the next post (Liana II) we’ll cover technical operation: creating policies, signing transactions, monitoring expirations, and disaster scenarios (simulating device loss, deliberate expirations).