add liana support

[plebhash]

Liana is a simple Bitcoin wallet with built-in loss protection and inheritance.

Current status: draft.

Roadmap:

• pkgs/liana/default.nix builds lianad + liana-cli
• WIP modules/liana.nix + module integration tests (example)

cc @darosior

[storopoli]

Isn't it better to move these hardcoded defaults to example instead of default.
I can see easily an user shooting himself in the foot.

[plebhash]

ideally this should come from options.services.lianad.*, and it definitely makes sense to remove this default value, but with the tradeoff that options.services.lianad.main_descriptor must become a mandatory option.

unfortunately lianad's CLI is still very limited, so everything needs to be written indo a config.toml, and lianad will not start unless there is a valid descriptor inside config.toml

so the challenge here is:

• declare all options from this sample lianad_config_example.toml as options.services.lianad.* inside modules/liana.nix so they're available as systemd configurations (which seems to be the most common pattern across nix-bitcoin modules)
• make sure these configurations are taken from options.services.lianad.* and used to generate a config.toml on the module's output (ideally placed somewhere like /var/lib/lianad)

I started doing a heredoc inside the preStart but still unsure whether that is the best approach. It feels a bit dirty tbh.

Also, while the variables are still hardcoded on the heredoc, the idea is to take their actual values from options.services.lianad.*. There heredoc includes some comments. But again: heredoc might not be the best approach.

[storopoli]

Yes but still in a footgun for the user.
Check my comment below on how to interpolate TOML file contents into a string.

[plebhash]

not really, this is a proposal to mitigate the footgun

• the user MUST provide a options.services.lianad.main_descriptor on their configuration.nix, which in turn is used to dynamically generate a config.toml file on disk of the output's datadir
• failing to do so blocks the module from ever launching a systemd service, because there's no valid config.toml in disk

the heredoc is still hardcoding things, but hopefully something along these lines will be a viable approach:

        cat << EOF > lianad_config.toml
# these should come from options.services.lianad
- daemon = false
- data_dir = "/var/lib/lianad"
- log_level = "debug"
- main_descriptor = "wsh(or_d(pk([0dd8c6f0/48'/1'/0'/2']tpubDFMbZ7U5k5hEfsttnZTKMmwrGMHnqUGxhShsvBjHimXBpmAp5KmxpyGsLx2toCaQgYq5TipBLhTUtA2pRSB9b14m5KwSohTDoCHkk1EnqtZ/<0;1>/*),and_v(v:pkh([d4ab66f1/48'/1'/0'/2']tpubDEXYN145WM4rVKtcWpySBYiVQ229pmrnyAGJT14BBh2QJr7ABJswchDicZfFaauLyXhDad1nCoCZQEwAW87JPotP93ykC9WJvoASnBjYBxW/<0;1>/*),older(65535))))#7nvn6ssc"
+ daemon = ${options.services.lianad.daemon}
+ data_dir = "${options.services.lianad.data_dir}"
+ log_level = "${options.services.lianad.log_level}"
+ main_descriptor = "${options.services.lianad.main_descriptor}"

I'll give it a try at some time later.

[storopoli]

This could be a builtins.fromTOML follwed by a toString, e.g.:

let
  tomlFile =./example.toml;
  tomlData = builtins.readFile tomlFile;
  tomlObj = builtins.fromTOML tomlData;
  tomlString = toString tomlObj;
in
  tomlString

Then you can interpolate the hardcoded nastiness with options.services.lianad.*

[storopoli]

Refs:

• https://nix.dev/manual/nix/2.22/language/builtins.html#builtins-fromTOML
• https://nix.dev/manual/nix/2.22/language/builtins.html#builtins-readFile
• https://nix.dev/manual/nix/2.22/language/builtins.html#builtins-toString

[plebhash]

will this allow me to dynamically generate the TOML file and write it into the output's datadir?

it seems like a convenient tool for reading configs that already exist on disk, but our use case is the opposite direction:

we need to generate a TOML file with values coming from options.services.lianad.*, because lianad only launches with a valid config.toml coming from disk

[storopoli]

Yes but still in a footgun for the user.
Check my comment below on how to interpolate TOML file contents into a string.

[0xB10C]

Would upstreaming this into nixpkgs make sense? There are a bunch of Bitcoin related packages and services in nixpkgs already.

[dunxen]

Would upstreaming this into nixpkgs make sense? There are a bunch of Bitcoin related packages and services in nixpkgs already.

I already maintain the liana package in nixpkgs. https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/li/liana/package.nix

[plebhash]

Would upstreaming this into nixpkgs make sense? There are a bunch of Bitcoin related packages and services in nixpkgs already.

I already maintain the liana package in nixpkgs. https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/li/liana/package.nix

that's awesome @dunxen thanks for sharing!

I actually went for different tradeoffs on the liana/default.nix currently living on this PR

nix-bitcoin is usually headless, so liana-cli + lianad are a 1st class citizen on the approach here

are you open to PRs expanding nixpkgs/tree/master/pkgs/by-name/liana/package.nix to include those two binaries + config file? that way, nix-bitcoin could simply consume nixpkgs

[dunxen]

are you open to PRs expanding nixpkgs/tree/master/pkgs/by-name/liana/package.nix to include those two binaries + config file? that way, nix-bitcoin could simply consume nixpkgs

Sure, thanks! It would be one package definition but with attributes to choose what to build. So I'd imagine that if you install lianad then it would result in the lianad and liana-cli binaries, else if you do liana then it is the GUI (only?).

Kind of how bitcoin does it in nixpkgs:

https://github.com/NixOS/nixpkgs/blob/a71e967ef3694799d0c418c98332f7ff4cc5f6af/pkgs/top-level/all-packages.nix#L35801-L35810

So we'd need to define liana and lianad in all-packages.nix again since we'd need to change those attributes.