Featuring the integration of Taproot and the Coldcard signing device, the version 5 of Liana is certainly our largest release yet. In addition to these bragworthy features, a lot of work was put into improving the user experience in the GUI. And this is only the beginning: making the wallet more usable and accessible will be one of our main goals for version 6.
Download Liana v5 here. For questions or to contribute thoughts and feedback, join our Discord and Telegram groups.
Coldcard support
Coldcard has been requested for a while. And before, we were requesting them! We started bugging them to implement Miniscript support back in 2021 when working on Revault. Then we never stopped until they finally released experimental support in their Edge firmware last year.
Shootout to Andrej Virgovic for leading this effort and for the communication with us as we were implementing support. He was responsive and quick to implement fixes for the challenges we encountered.
You can already try Liana with your Coldcard by using the Edge firmware. Hopefully our release will help further test their Miniscript implementation to promote it to the stable firmware.
Experimental Taproot support
Yes. It’s here. Finally. It’s probably the most requested feature ever. And it was planned from the beginning: it’s not an accident if Liana is named after a plant with numerous long twining branches!
We’ve come a long way since Miniscript was not yet specified for Taproot. Unfortunately not all signing devices we support have this feature yet. For now, only the Ledger supports Taproot-Miniscript in production with their latest version of the Bitcoin app. Coldcard has Taproot directly in their Miniscript implementation. Bitbox plans to add support whenever they manage to overcome an unrelated technical limitation. Specter has implemented the support but hasn’t released it yet.
A major requirement for a proper integration of Taproot in hardware wallets is to be able to deterministically derive an unspendable internal key, in case the descriptor should only be spendable through a script path. This is so your device can tell you:
That’s fine, this key you don’t know is not able to sweep all your coins immediately!
In practice, it would just check the key is unspendable and not show it to you at all. Having descriptors without a spendable key path is not uncommon. This is the case in Liana for instance if you use a multisig as your primary path (for instance in a “decaying multisig” construction).
But as Salvatore Ingala explains in his Delving post we don’t want just any unspendable Taproot internal key, we want one which:
- is deterministically derivable from the rest of the descriptor, and only from the descriptor;
- is verifiably unspendable;
- yet is indistinguishable from a spendable internal key by an external observer.
Liana ships with a scheme which has the 3 properties above. In simpler terms: if you use a Taproot multisig in Liana, no external observer will know that you don’t have a keypath spend available, and you don’t have to backup any more information than your descriptor to be able to recover!
Spend transaction creation UX improvements
The automated coin selection now also considers unconfirmed coins. This was a bit involved to implement: unconfirmed coin means unconfirmed parent transaction. This parent transactions may be large, and may have a lower feerate than the one targeted for the new Spend transaction. Therefore we implemented CPFP (“Child Pays For Parent”) logic in this case: we’ll bump the feerate of the Spend transaction we are creating to bump the feerate of the whole package to the target feerate.
To avoid a trivial double spend attack by default we only select coins which originate from a wallet transaction. That said this CPFP logic can be leveraged to bump the fees of a received payment, since you can simply select which coins to spend when creating a transaction. To do so, just go to the list of coins screen and click “refresh” on the appropriate one. Set the feerate you want to bump it to and the CPFP logic will automagically create a send-to-self transaction which bumps the incoming transaction to this feerate.
There is also a new “MAX” button next to each recipient when creating a Spend. This allows to sweep the funds to this recipient, minus the amount allocated to other recipients. By default it would sweep all the funds in the wallet, but if you select specific coins through coin control it would only sweep those coins which were selected.
Finally, we made two small changes which significantly improve the usability of the wallet on a day-to-day basis:
- signing a transaction does not monopolize the screen anymore. You can browse the details of your transaction as you are confirming on your signing device. Better yet, you can sign on multiple signing devices in parallel;
- changing screen does not erase your spend transaction draft anymore. You can move to the transaction list or the homepage to check something and get back to the transaction you were editing.
See our release notes for a full list of the UX improvements, in the spend creation and elsewhere!
Conclusion
Try Liana. We have a guide on the Github to quickly try it out on Signet.
Join our Discord and Telegram groups to share feedback or ask questions.
Liana is an open source project, join our Github and start contributing code, thoughts or documentation! Look out for the “Good First Issue"s.