From a security standpoint, why might a desktop c-lightning user need an additional lightning wallet?

Question

Many c-lightning tutorials on YouTube walk their listeners through the process of setting up a c-lightning node followed by the installation of a wallet like Spark-wallet. I just don't get it why do I need such a lightning wallet.

My setup

Ubuntu Desktop LTS. Pruned Bitcoin Core with connections over Tor. To make transacting through my c-lightning node more convenient I wrote this script. I'm well aware that I could have written something even simpler were I to do it in Bash instead of in C. I aliased in my .bashrc the path to the script, i.e. to its binary, like so alias lcli='~/CS/SoftwareDevelopment/MySoftware/C/lcli/a.out' and the command to start the lightning daemon: alias ldaemon='lightningd --daemon'

My routine looks like so: 1. cd ~/.lightning/bitcoin && ~/CS/Bitcoin/c-lightning/lightning/tools/lightning-hsmtool generatehsm hsm_secret I introduce the seed phrase which generates an unencrypted hsm_secret(I use no passphrase to generate it, just the seed). lightningd.sqlite3 is already there and my pruned Bitcoin Core is running all the time.

2. I type lcli in the terminal and then interact with my script.

3. After transacting I shut down lightningd (through the same script).

4. I backup my lightningd.sqlite3 with another script and remove my hsm_secret.

Why would a user like myself want to use any wallet (other than that of their c-lightning node) at all? Can use of such a wallet offer any security advantages that I'm not aware of? Is my routine of transacting insecure?

Answer 1

Let me clarify some things here with the order

Many c-lightning tutorials on YouTube walk their listeners through the process of setting up a c-lightning node followed by the installation of a wallet like Spark-wallet. I just don't get it why do I need such a lightning wallet.

c-lightning accepts request only through the UNIX socket and this means that you can not use HTTPS to access it. This brings two problems:

1. You can not have a remote node and control it from outside your local network.
2. If you expose the API through a Rest API you need to manage the authentication, many tools did it with a js server or a plugin like jrest.

Spark Wallet is a web interface from c-lightning that exposes the API through rest protocol and gives you the possibility to manage the node with a mobile/web interface. So if you love the command line, c-lightning is enough

Ubuntu Desktop LTS. Pruned Bitcoin Core with connections over Tor. To make transacting through my c-lightning node more convenient I wrote this script.

Each run of your node is a lucky run because likely your lightning node asking for a block not yet removed by bitcoin core prune mode. There are plugins that implement safely the pruning mode like btcli4j

My routine looks like so: 1. cd ~/.lightning/bitcoin && ~/CS/Bitcoin/c-lightning/lightning/tools/lightning-hsmtool generatehsm hsm_secret

Super Safe I think so, you backup the node each run, but there is some corner case here. I will also assume that for now there is no "good" way to use a lightning network node, but also here there is another corner case, that I will explore below:

What is a lightning node (November 13, 2021)

There is no difference between lightning nodes right now, but we can make the following distinction:

• Node that wants to use the lightning network to pay (only!)
• Node that wants to be part of the network, so it pays and helps the other person to make payment (forward payment)

Now, you are in the first subset, so you use the node only to pay to throw a single private node, and it works because you are only one node and you pay directly to this node (A -> B). You can use also a key send option.

But when you could have a problem? A problem can be when you will add a new channel to your network (aka: C), in this case, your payment can fail because your c-lightning node applies a technique that is called multi-part payment aka MPP, where the basic idea is to split the payment across channels, but if one of your channel capacity it is not enough, and it has not another alternative, it can fail.

Conclusion

• Your procedure is it right? Depends on what you want to do, but yes for your use case. However, it will fail for the corner case described above.

In addition, the lightning network node is more from your usage, but it is also true the usage depends on what you want to do with lightning.

P.S: Another corner case is if you are a public channel aka D with another node, but this time id D with a channel open to you (D->A) and you are offline all the time, the node could (or should) want close a channel, because you are locking some funds with your bad uptime.