We just released the second iteration of Liana, which makes it significantly simpler to install and create a Liana wallet. It also fixes a couple bugs and glitches.
You can download the latest version of Liana on our webpage and inspect the detailed changelog since 1.0 on our Github.
In this post i’ll go over the highlights from this release.
Packages and distribution
An unglamourous but handy new addition is packages for various Linux distributions. We now
distribute a .deb package for Debian-based operating systems (for instance, Ubuntu). For
Arch-based distributions (think, Manjaro) we also pushed a liana-bin package to the
AUR.
For most Linux users installing Liana is now (virtually) one apt install or paru -S liana-bin
away. This brings our ditribution of binaries for Linux on par with the Liana.zip for MacOS,
Windows’ non-codesigned .exe being the last one lagging behind.
In addition, users can now download the binaries directly from our webpage. See “Download Liana” at wizardsardine.com/liana.
A completely managed Bitcoin Core
Liana requires a Bitcoin Core node running in the background to fetch data from the Bitcoin network.
It’s been widely reported to be cumbersome for users to have to fiddle with starting a bitcoind
themselves. Especially on Windows.
This release brings a completely managed node from the Liana graphical interface, contributed by
@jp1ac4. During installation, one can opt in to let Liana manage their bitcoind. It will download
it from https://bitcoincore.org, verify it, and start it with a pruned historical block chain. The
node gets stopped when exiting and started upon starting up Liana.
IBD still needs to be performed, but no more fiddling with the command line required. And less moving parts. We hope IBD can be made more bearable in the future by leveraging the upcoming Bitcoin Core feature AssumeUTxO.
Reused xpubs
Another way we’ve made the installation easier was in letting users copy-paste the same xpub across spending paths when creating their descriptor. It’s very common to be willing for an xpub to appear for instance in the main spending path, and in one (or more) of the recovery paths. However, you can’t have duplicate keys within a Miniscript descriptor. Our approach with v1 was to let users generate multiple xpubs either directly from their own signing device or from the “participate” screen when creating a multisig.
It turns out this wasn’t obvious (some users missed it) and unnecessarily complicated. There is no need to generate multiple xpubs per signer. Instead, we’ve updated this flow to use different unhardened derivation indexes from the same xpub when using it in more than one spending path. It also makes it easier to verify the wallet policy on the signing device.
Note descriptors containing those xpubs would not be accepted by previous versions of Liana. Upgrading from Liana v1 to v2 should be trivial though.
What’s next?
We’ve got plenty of feature requests to pick from. After improving the installation UX in v2, we are planning to improve the usability of the wallet itself in v3. We’re focusing on integrating the Bitbox02 signing device (for which Miniscript support was recently released) and labels for addresses, coins and transactions.
We are also looking into integrating the Coldcard’s experimental Miniscript support as well as automated coin selection.
Contributions
We are continuing to get more external contributions, which is really encouraging. After the shoutout to @jp1ac4 in the previous release’s blog post, we are honouring @Pythcoiner for his relentless testing, support for users and for contributing a guide to recover a Liana wallet backup using nothing but Bitcoin Core 25.0.
Thanks to everyone who contributed feedback or bug reports so far. Keep them coming! For small issues and casual discussions around Liana feel free to join our Telegram group.