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:
- You can not have a remote node and control it from outside your local network.
- 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.
- 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.