Topic: The Lightning Network FAQ - page 72. (Read 32053 times)

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

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:

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)

You cannot derive channel states from the hsm...

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

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.

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

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?

Exactly!

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.

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.

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).

Ok, that's clear.

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

Are these plugins available somewhere? What do you use?

Hello Samuel,

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


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 !).

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.

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?

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.

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

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...

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

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).

*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*

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

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.

as you've seen, this is a known bug in lnd, for which there is currently no fix. I don't know if this is affecting arm64 builds (RasPi nodes are arm64), but if so this is pretty bad news, as most people are opt for lnd because the daemon is provided as a pre-built package (LL have been good in that respect, there are alot of OS's and platforms supported with builds and prebuilt binaries, don't know if that's because golang makes that easy, I suspect so)

try using c-lightning as the fix lnd has other resource usage issues right now (uses alot of RAM), if you're running multiple nodes I would guess resource usage per-daemon could be important to you. 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. That's not to say that c-lightning is perfect (they've been wrangling bugs too), but resource usage has not been an issue. You'll need to sync the channel map as with lnd, but maybe you'll appreciate that you can use PostgreSql with the db seeing as you're doing something that sounds demanding

Hi, I have been working on a project where I need to run lots of lnd services on a single machine (physical or virtual, does not matter). In theory, it seems easy, I created a directory structure for each node with its own conf file, tcp ports and so on. It was not difficult and I started 16 nodes for a test on a single VM machine. (CentOS 7)
After starting them, each node begins to update network graph (file channel.db in /data/graph/mainnet); this process is quite long and CPU consuming. After the graph is updated, an lnd service is supposed to go into idle mode with low cpu usage. In reality, this happens but not for a long time. At first, CPU usage stays low but only for a couple of hours, then all services one by one started loading CPU heavily with no reason. The lnd services will not stop doing that until I restart them, then everything happens all over again. One interesting thing is that the bitcoind service does not use almost any CPU resourses; it means that lnd services do not use bitcoind, when they load CPU. I could not find anything unusual in the lnd logs, everything seems normal.
I don't understand what's going on and ho to fix it. My host's hardware should be enought for the purpose (Core i3-3.8Ghz/16Gb RAM/SSD) Maybe somenody has already come accross with this issue. I fould the similar issue on the lnd's github page but there is no solution there.
https://github.com/lightningnetwork/lnd/issues/3370
I am interested to listen to everyone who has any thoughts about it or solutions how to fix it.

yes, you commit the channel states onchain, but do not connect to nodes on the "main" Lightning network (and so you don't announce your channels on the main network either). Of course, the opening tx's are can only be created using the public internet, but then your alternative Lightning network can be set up on a completely private network (and that comes with all the liquidity and trust trade-offs as mentioned before)

Connecting to the main Lightning network today is like a trip back to the 1990's; you look up a list of LN node IP addresses on a listing site, connect to one, it tells you the current (entire) channel map, then you start making channels at your discretion using the current map. There's absolutely nothing stopping you getting together with a bunch of other people and starting an alternative LN network from scratch, you just need LN nodes and each others IP addresses.

they didn't know the risks, and screwed up trying to close a channel using an outdated transaction (i.e. an old channel state)



yep, that was too risky considering they didn't close their channel competently. Every time you send a large amount of money anywhere, on any system, you should be triple-sure you know what you're doing.



nope.

You're probably thinking of the eltoo form of Lightning, which avoids this problem. You cannot make that mistake using eltoo, but it's a long way off (new opcode required, and the details are still being debated, in an already long debate)

Thanks for the suggestion. If a mesh network can be established in the region, then this can be a good solution, but it would also be more suitable for urban areas (in most places of Venezuela, however, it should work). As far as I understand the LN architecture, that "private network" would use the same channels (i.e. the same multisig channel opening transactions) than the "real LN", only that the "communication layer" would change, so no additional on-chain TX would be necessary which is the important feature we are seeking ... (correct me if I'm wrong)

@rdbase: Seems to be the same case like the one Khaos77 mentioned, the user simply broadcasted the wrong transaction to close the channel. I would strongly favour to not discuss this topic here as it's the user's fault (it's possible however that the LN software could have been designed to prevent this).

How was it even possible to lose bitcoin using this network?
This user reported they lost 4btc using lightning. https://bitcointalksearch.org/topic/m.52855065
Wasnt it created inorder to not being susceptible for such things to happen?