Topic: The Lightning Network FAQ - page 43. (Read 33446 times)

that's just saying what I said, slightly differently

the C language lets you control resources. Golang mostly does not.

c-lightning is written well enough that it uses resources efficiently. LND consistently has issues. That's OK is you're running it on an expensive server, and you only want to run one lightning node on the server.

Having used C since I was in high-school in the mid 80s I can say that it has it's own set of debugging issues when it comes to CPU / RAM problems.

I like RPis, I use them everywhere. BUT $100 machines like this are all over: https://www.ebay.com/itm/144041689234 just swap the spinning drive for a SSD if you want and you are way ahead of running a RPi3
A programmer I use in India has been getting the above machine with a 128GB SSD (yes I know you can't run a node on it) for under 5000 Rupees at a local shop so it's not just a US thing.
IMO you should be on a RPi4 with more ram anyway when running a node and anything else on it.


Agree with Carlton but if you want to test anyway, let me know and I'll spin up one of nodes running c-lightning and get it updated. Might take a day or 2 since I have not been using them for a while.

-Dave

with a fully-fledged server, you can run multiple lightning instances anyway. Maybe running 1 or 2 LND's will prove useful for different reasons, I'm not currently in your position where I have a decent enough machine to try.

Maybe keep the Pi as a local watchtower, powered (also the internet router) with a UPS? Or at some other location, of course.

Try the clboss plugin for Lightning, you can dial down/switch off some of the features if you want to: https://github.com/ZmnSCPxj/clboss


wait till version 0.10.1, or compile/run master branch, the spec for dual fund has slightly changed. I'm hoping that the clboss plugin will seek out nodes to dual fund with automatically once the spec is finalized.

Thanks Carlton for your write-up! I have recently decided to switch from a Raspberry Pi to a normal server. Since LND does not recommend reusing the channel database between different architectures, I had to close all of my channels. I was thinking about using a different implementation this time. You sold me on c-lightning. I am going to miss Zap Wallet, though. Spark Wallet isn't nearly as good.

Would there anyone here be interested in testing out dual-funding once the transaction fees have gone down?

You forgot Groestlcoin (seriously, I even think to remember they were the first coin who implemented it).

It is even possible to exchange coins via Lightning, but then both participants need a channel for each coin obviously. So it's not a really "easy" way to swap coins, at least if you want to do it without a centralized intermediary.

OmniBOLT also allows tokens to be used on Lightning (on Bitcoin), but I guess you need a separate channel for each token (can someone confirm this?).

Litecoin and (I think) Vertcoin also have Lightning implementations, but in terms of usage, I get the impression they're pretty limited.  There's not nearly as much liquidity on those chains.  In essence, you'll find it easier to make payments with LN using Bitcoin, compared to altcoins.

Well, at the moment I believe that it's only available for Bitcoin. There is a serious problem with small micro-transactions in contrast with its forks. Litecoin for example doesn't necessarily need LN since a transaction costs up to 4 cents.  (~0.00000051 LTC)

Are you asking if it has been implemented or if it's possible to implement it? If we're talking about the second, it surely is. At least, for the forks of Bitcoin you probably won't have to make big changes in the variables.

The Lightning Network is a protocol, not a token.

seems like a mistake

because LND's written using golang, the devs are having to deal with golang's problems

1. Difficult to find bugs where the CPU usage has frequent 100% spikes
2. High memory usage, again where spikes are sometimes difficult to explain

using golang makes it hard(er) to control that sort of thing, and it's by design, because the idea is that the programmer can focus on writing the app, not on the subtle job of also making the app talk to the operating system

c-lightning uses minimal RAM and CPU, because it's written in C, where the programmer must directly control almost everything the app does (with golang, a bunch of Google-written magic does the job for you)


So really, these small rPi nodes (and bigger servers with more than one LN node per machine) are better off ditching LND.

It's becoming more clear this will be necessary as Lightning gets more actual use; I'm running c-lightning on an rPi 3, and when the network is quiet, all is well with system resources (I've got 2GB swap space on an SSD to ameliorate the low RAM). But when there are big storms of transactions, the gossip updates push the CPUs to ~ 50%. There will be even more bigger surges in future, I expect


If LND don't fix their problems before Lightning use gets more regular (and heavier), these little rPi nodes won't be able to handle it.

Besides, LND seems to exist to sell a bunch of services to you anyway (swaps and watchtowers), c-lightning is focusing on supporting a more peer-to-peer dynamic (dual-funded channels). LND is coming to represent what critics say about Lightning: resource heavy and centralized

Lightning Network for use with bitcoin only right?
Can Lightning Network use with other alt coin?

Can Lightning Network create as new alter coin and fast same?

https://bitcoinmagazine.com/technical/first-dual-funded-lightning-channel-opens


Dual-funded Lightning channels are now possible. Obviously once implemented by all the other Lightning implenentations, it makes Lightning usage more practical on both user side and merchants/services side. It might be this upgrade merchants/services need to actually start offering Lightning as a payment option.

And the entire communications chain has to remain active end to end until the lightning transaction has been accepted.
Each node only talks to the next one and then back. But, yes until it's all done each node needs to know the status of the next.

-Dave

To have a better understandment of this, I try to make this analogy: is LN like an OSPF (link state) network topology, where each node, at least when it send a tx, needs to know the entire route, reaching the destination when being able of opening a TCP socket with the last peer?

Is not like a distance vector network topology, where a node just need to know the state of the nearest peer and not the entire path, correct?

Yes, that is with just about anything behind NAT without port forwarding.

You have a public IP, behind the router that is in front your can have just about any number of devices. When a packet of data hits the public IP, if the firewall / router does not know what to do with it, they drop / discard it. If there is port forwarding running, it knows that data coming in on port X goes to a certain device on the private side.

There are some automated ways of doing this, and some other trickery to work around it but none of them are 100% reliable.

-Dave

So basically, per protocol, a node behind nat, even if it's connected to a public node, doesn't become able to receive routed payments. It just stay private, correct?

Is it possible to forward port 9735 from the public to the private side?
I do not think NAT will work since your router / firewall will just dump incoming packets that it does not know how to route and lnd does not use any form of upnp.

If you cannot forward the port there is always the option to use TOR.

-Dave

Question:

I've a public node (raspiblitz) with public IP, and with this node i'm able to interact in both ways (sending and receiving) without problems, even with routed payments.


To try LN better, i've also opened a LN wallet/node with electrum, on a connection behind a NAT. I've then opened a channel from electrum to the raspiblitz

Now the problem:

If I try to send a routed payment from electrum to... let's say coingate, no problem.

Ex: LN ELECTRUM (BEHIND NAT) > LN RASPIBLITZ > LN COINGATE


If I try to send a payment from the raspiblitz to electrum, also no problem

Ex: LN RASPIBLITZ > LN ELECTRUM



If I try to send a routed payment from coingate to electrum, even having capacity on both the raspiblitz and coingate, it cannot be completed.


Ex: LN COINGATE > LN RASPIBLITZ > LN ELECTRUM


I suspect that this could be a nat problem, but I thought that since electrum has a permanent TCP socket open with the raspiblitz, it would become reachable even behind NAT, to receive routed payments.

He also debated, almost commanded everyone to listen and accept because it’s “true” and a “fact”, that Lightning transactions are IOUs. It’s laughable to think because opening a channel requires an onchain transaction. They are literally Bitcoin transactions that haven’t been settled onchain yet.

Mostly, but not exclusively.

Thanks for your suggestion. I will probably overhaul this thread at some point. Still, I think that there are plenty of YouTube videos and Medium articles showing such basics. Although, I am not sure how up-to-date they are since I didn't look at any of them in a long time.


Sure, but with Taproot, no one will be able to tell if coins were locked up in a channel (unless that channel ends up being closed uncooperatively). That's a significant privacy enhancement.


You can see his deleted posts here. He was mostly arguing about Lightning not being Bitcoin.

I'm pretty sure that's a part of the point Frankie was trying to make a week or two ago and got shouted down for their efforts.