The Lightning Network FAQ

[samuel-sd]

if you're running multiple nodes I would guess resource usage per-daemon could be important to you.

You are damn right! 400Mb of RAM is a lot for a single lnd process with no channels at all.

FWIW, I'm running c-lightning on a Raspberry Pi 3B+ (1GB RAM) with a handful of channels, so no problems on low resource devices.

Tell me about c-lightning service, how reliable and stable it is? How much memory does it need?

PS I have spent so much time on lnd, automation, scripting and so on, and now I came across the bug that pushes me to use something else.

[1715349465]

1715349465

[1715349465]

1715349465

[1715349465]

1715349465

[darosior]

if you're running multiple nodes I would guess resource usage per-daemon could be important to you.

You are damn right! 400Mb of RAM is a lot for a single lnd process with no channels at all.

FWIW, I'm running c-lightning on a Raspberry Pi 3B+ (1GB RAM) with a handful of channels, so no problems on low resource devices.

Tell me about c-lightning service, how reliable and stable it is? How much memory does it need?

PS I have spent so much time on lnd, automation, scripting and so on, and now I came across the bug that pushes me to use something else.

*Shilling mode on*
How reliable ==> releases are quite stable, but it depends of how much you tweak it with plugins  
How much memory ==> just checked, with around 10-15 channels and more than 300 connections (yeah I'm doing test atm..) it does not use more than 10% of the 2GB of my node. Idle mode, might of course be higher when computing routes (I think that's the more usage incentive thing).

Anyway C-lightning aims at being as minimal (all non-vital things as plugins) and economic as possible : for example Rusty did a lot of performance improvements for last releases (tests are done on a RPi to use the less powerful hardware as possible), and a lot of bandwidth improvements for this one (v0.7.3) (gossip).
*Shilling mode off*

[Carlton Banks]

An arguable downside to c-lightning IMO is the lack of available builds (I imagine the devs want to make them reproducible before doing that). That's what's strange about lnd; they're releasing a product that's more like an alpha release than a beta release, yet they're distributing binaries of that alpha-ish product. As I said, I think golang makes this a little too easy to do, and so the LL people are running before they can walk.

Other downsides might be features... lnd probably has more features than c-lightning, but I think they're pretty close as far as the actual spec of the Lightning protocol goes (it seems c-lightning & lnd teams are coordinating development pretty closely along with the ACINQ team doing Zap/Eclair, although I know even less about their clients). But if you look at the work on efficient routing algorithms, it seems as though c-lightning might get ahead of lnd soon, according to what their development priorities seem to be recently. Also, c-lightning has the plugin system that Darosior mentions, I don't know enough to say whether there are not some available plugins that do things lnd can't.

overall, I get the impression c-lightning is in a better state of production-readiness than lnd, despite any lack of extra features (and I might be getting that part wrong).

[samuel-sd]

Thanks guys! I will give c-lightning a shot.

[darosior]

An arguable downside to c-lightning IMO is the lack of available builds (I imagine the devs want to make them reproducible before doing that).

Being in C (a lot of functionalities used are low level and system dependant, e.g. daemons interop) , I think we'll ever only have builds for POSIX systems.

Other downsides might be features... lnd probably has more features than c-lightning, but I think they're pretty close as far as the actual spec of the Lightning protocol goes (it seems c-lightning & lnd teams are coordinating development pretty closely along with the ACINQ team doing Zap/Eclair, although I know even less about their clients).

Hmmm I'm not sure ? What feature would you like to see on C-lightning ?

But if you look at the work on efficient routing algorithms, it seems as though c-lightning might get ahead of lnd soon, according to what their development priorities seem to be recently. Also, c-lightning has the plugin system that Darosior mentions, I don't know enough to say whether there are not some available plugins that do things lnd can't.

Development priorities are actually on dual funding and v1.1 spec (new invoices, AMP, etc..).
An example of a plugin doing JIT routing (i.e. rebalancing channels if needed while forwarding an HTLC) : https://github.com/lightningd/plugins/pull/66.
About LND pathfinding algorithm, I don't know much. I know however that they implemented scoring...

[samuel-sd]

Hi everybody!
Finally, I installed c-lightning, it uses about 22Mb of RAM and does not load CPU at all, everything looks good.
As far as I got it, c-lightning creates a wallet inside lightningd.sqlite3 file and there is a file hsm_secret, which is some kind of key, right?

So, the first question is how to backup onchain and offchain data? Before I start using it, I need to setup backups. It was quite clear with c-lightning, it gives me mnemonic key and has a backup file with all channel information. What about c-lightning?

[darosior]

Hello Samuel,

I'm glad that you are pleased with C-lightning 

As far as I got it, c-lightning creates a wallet inside lightningd.sqlite3 file and there is a file hsm_secret, which is some kind of key, right?

In the `hsm_secret` is stored the seed used to derive all keys (channels and onchain ones). You can consider it as the HD wallet seed.
In the `lightningd.sqlite3` (also available as a postgresql backend) is notably stored the channels state (aside a lot of other things !).

So, the first question is how to backup onchain and offchain data? Before I start using it, I need to setup backups. It was quite clear with c-lightning, it gives me mnemonic key and has a backup file with all channel information. What about c-lightning?

You can backup your onchain funds just by backing up the (potentially encrypted) `hsm_secret`.
You could backup your `lightningd.sqlite3` but it changes often (very often) and you should be very careful with restoring from backups.

For what it worth, efforts are being made for real-time database replication through plugins (some have been proposed) but it's harder than it seems and we have not yet found a satisfiable enough solution.

[samuel-sd]

You can backup your onchain funds just by backing up the (potentially encrypted) `hsm_secret`.

Ok, that's clear.

You could backup your `lightningd.sqlite3` but it changes often (very often) and you should be very careful with restoring from backups.

Is there anything like lnd backup? An independent backup file, which changes every time when channels' balance changes.

For what it worth, efforts are being made for real-time database replication through plugins (some have been proposed) but it's harder than it seems and we have not yet found a satisfiable enough solution.

Are these plugins available somewhere? What do you use?

[darosior]

You can backup your onchain funds just by backing up the (potentially encrypted) `hsm_secret`.

Ok, that's clear.

You could backup your `lightningd.sqlite3` but it changes often (very often) and you should be very careful with restoring from backups.

Is there anything like lnd backup? An independent backup file, which changes every time when channels' balance changes.

Hmm that's `lightningd.sqlite3`.. I don't think there is much sense in having another file which is updated at the same time `lightningd.sqlite3` is updated and that contains the same informations.

For what it worth, efforts are being made for real-time database replication through plugins (some have been proposed) but it's harder than it seems and we have not yet found a satisfiable enough solution.

Are these plugins available somewhere?

You have a lot of plugins here, the plugin I had specifically in mind is this one by SimonVrouwe which you should not use because the database structure changed since.

What do you use?

In terms of plugins or safeguards ?
For plugins I use:
- summary
- rebalance
- drain
- probe
- reckless
- and soon the JIT routing one

For safeguard I use:
- ..................  

No more seriously I have some hacky and nasty scripts for my database but I think the change has to come from the protocol. For example we now have (and I'm working on making C-lightning default to this) `option_static_remotekey` which allows you to recover your funds after the remote side unilateral close just with you hsm_secret (related but I made a mistake I have a tool for fund recovery which I plan to clean up and re-PR when we default to this).

[samuel-sd]

Hmm that's `lightningd.sqlite3`.. I don't think there is much sense in having another file which is updated at the same time `lightningd.sqlite3` is updated and that contains the same informations.

In this case I can have one lightningd.sqlite3 on my node and another one in a cloud (I used NFS storage on a cloud vps)
lightningd.sqlite3 stores not only channel balances but lots of other stuff. lightningd.sqlite3 changes too often

For safeguard I use:
- ..................  

Let's imagine my hard drive failed or there was a power outage or something else happened and I am not sure if the lightningd.sqlite3 is intact (or I lost it). I restored onchain data from hsm_secret. What should I do to get my node up and running again? What about my channels and funds in them?

I think the change has to come from the protocol

Exactly!

[samuel-sd]

I'm glad that you are pleased with C-lightning  

Yay! It finally works!  

I built a network structure with an lnd node as a main hub and many c-lightning nodes as points.
The hub has a few channels with well connected nodes and points have channels only with the hub.
I just sent a few transactions from outside to one of my points and the hub transferred the payments and collected fees.


(A)------>(B)----->(C)----->(D)

As far I got the fee system, if node A sends a transaction to node D, node B will collect a fee from the channel between B and C and C will collect a fee from the channel between C and D, right?
Nodes cannot collect fees from incoming channels, only from outgoing?

By the way, I found that c-lightning daemons use 170Mb of RAM (lnd uses 400Mb) and they use CPU gently when they download the network graph. They don't use all available CPU resources no matter what it takes.

[darosior]

Hmm that's `lightningd.sqlite3`.. I don't think there is much sense in having another file which is updated at the same time `lightningd.sqlite3` is updated and that contains the same informations.

In this case I can have one lightningd.sqlite3 on my node and another one in a cloud (I used NFS storage on a cloud vps)
lightningd.sqlite3 stores not only channel balances but lots of other stuff. lightningd.sqlite3 changes too often

For safeguard I use:
- ..................  

Let's imagine my hard drive failed or there was a power outage or something else happened and I am not sure if the lightningd.sqlite3 is intact (or I lost it). I restored onchain data from hsm_secret. What should I do to get my node up and running again? What about my channels and funds in them?

You cannot derive channel states from the hsm...

I think the change has to come from the protocol

Exactly!

[/quote]
That being said, it's not __that__ simple: basically tradeof is often taken over privacy..

[darosior]

I'm glad that you are pleased with C-lightning  

Yay! It finally works!  

I built a network structure with an lnd node as a main hub and many c-lightning nodes as points.
The hub has a few channels with well connected nodes and points have channels only with the hub.
I just sent a few transactions from outside to one of my points and the hub transferred the payments and collected fees.


(A)------>(B)----->(C)----->(D)

As far I got the fee system, if node A sends a transaction to node D, node B will collect a fee from the channel between B and C and C will collect a fee from the channel between C and D, right?
Nodes cannot collect fees from incoming channels, only from outgoing?

Fees are taken as a delta between received payment and sent payment, basically you receive more on you incoming channel than you send on the outgoing one.
With your above example a simple schema would be:

Code:

# A wants to send 10000msat to D
# D only accepts incoming HTLCs with at least 9 as CLTV value
# A computes a (naive) route backwards

amounts:                      10003msat              10002msat             10000msat
                      (A)      ------>       (B)      ----->      (C)      ----->     (D)
CLTV deltas:                     15                      13                  9
# In this scenario (C) took more fees than (A) and imposes a bigger CLTV delay for outgoing HTLCs

By the way, I found that c-lightning daemons use 170Mb of RAM (lnd uses 400Mb) and they use CPU gently when they download the network graph. They don't use all available CPU resources no matter what it takes.

Recent optimisations have been made with gossip and thus it's now less resource incentive (less bandwidth consumption, so maybe also less CPU consumption ? Didn't benchmark it)

[RapTarX]

LN will never be solution, Satoshi said that onchain transactions will support miners in the future, with LN there is no fees for the real miners that support blockchain, with time the fee of one ON-CHAIN transaction will be huge.

LN still need on-chain transaction to open and close channel

As long as I am not closing a channel, I can settle any transaction. Won't it reduce the on-chain transaction heavily? Which is good in some case though but still cfbtcman question is there.

Well, I am a newbie in LN, not much old in Bitcoin as well.

For me, until now, LN is-



Here- Bob (X) is a client who used to shop with BTC. Since the fee is high, he is looking for alternative way, hence he got LN.
He knows if he creates a channel with Y(Route?)- who already have channel with a lot of Bob's favorite shop, he can settle a lot of payments in most of the shops he is used to go daily.

I am trying to learn it from the perspective of a client of a lot of shops so that I can pay micro payments with bitcoin.
Please correct my above statement, for last 3/4 days, I am spending a lot of time into LN. Have read some parts of the whitepaper here- https://lightning.network/lightning-network-paper.pdf

[samuel-sd]

Hi! I have a couple of question about c-lightning
The first question:
As far as I understood, c-lightning wants to run bitcoin-cli executable in order to communicate with bitcoind service. In my case, I would like to run c-lightning in its independent docker container and it would be nice if c-lightning works only with its own files and libraries. Is there any way to use c-lightning without providing bitcoin-cli?
LND, for example, is able to communicate with bitcoind through a tcpip port without using any bitcoind files. Can c-lightning do the same somehow?

The second question
I want to use c-lightning nodes only for receiving funds, in my case a c-lightning node is not going to send any bitcoin, only receive it. I know that lightningd service gathers and processes the graph information from the network. This process consumes lots of memory and CPU resources, but I don't think it’s necessary in my case, because this information is required only for sending bitcoin not receiving it. May I switch the lightningd to the mode, when it will just maintain the only channel it has and provide invoices/wait for incoming transaction without downloading and processing extra network information?

[darosior]

Hi,

Hi! I have a couple of question about c-lightning
The first question:
As far as I understood, c-lightning wants to run bitcoin-cli executable in order to communicate with bitcoind service. In my case, I would like to run c-lightning in its independent docker container and it would be nice if c-lightning works only with its own files and libraries. Is there any way to use c-lightning without providing bitcoin-cli?

There are docker provided, but with `bitcoin[d/cli]` integrated.

LND, for example, is able to communicate with bitcoind through a tcpip port without using any bitcoind files. Can c-lightning do the same somehow?

Not for now, but that might change in the near future.

The second question
I want to use c-lightning nodes only for receiving funds, in my case a c-lightning node is not going to send any bitcoin, only receive it. I know that lightningd service gathers and processes the graph information from the network. This process consumes lots of memory and CPU resources, but I don't think it’s necessary in my case, because this information is required only for sending bitcoin not receiving it. May I switch the lightningd to the mode, when it will just maintain the only channel it has and provide invoices/wait for incoming transaction without downloading and processing extra network information?

This cost has been drastically reduced in the last release, however if you want 0 gossip you can still compile with `--enable-developer` and use the `dev-suppress-gossip` command.

[samuel-sd]

however if you want 0 gossip you can still compile with `--enable-developer` and use the `dev-suppress-gossip` command.

Thanks a lot! You made everything clear.
Is there any way to download clightning binaries which were compiled with `--enable-developer`? Maybe they are shared as a regular version.

[Adriano2010]

Hi. What i want to ask is, if possible can i run a lightning node on my pc 24/7 or i should buy a server or vps for this? Maybe server is safer. And how much bitcoin i need to start a lightning node/channel?

[darosior]

Is there any way to download clightning binaries which were compiled with `--enable-developer`? Maybe they are shared as a regular version.

No, but building C-lightning is really straightforward.

Hi. What i want to ask is, if possible can i run a lightning node on my pc 24/7 or i should buy a server or vps for this? Maybe server is safer. And how much bitcoin i need to start a lightning node/channel?

Hi,

As you want.
Running one on your host is completely feasible and I think that's what most of people do (according to some stats made by Christian Decker and presented at TheLightningConference).
A server is not "safer", but will make you a better routing node as you will have a far better uptime.
There is minimum required, but in practice some node force a minimum to open a channel with them. You could try out the Lightning Network just by opening a few channels of few millis worth.

[LiberOptions]

Hi guys,

I have recently decided I had to get a Lightning wallet and wanted to hear from you guys

What are the best wallets compatible with lightning?

Can I use the lightning network for long term storage?

Thanks