The Lightning Network FAQ

[Timelord2067]

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.

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

Mostly, but not exclusively.

[1714788554]

1714788554

[Wind_FURY]

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.

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

Mostly, but not exclusively.

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.

[alexrossi]

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.

[DaveF]

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

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

[alexrossi]

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

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

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?

[DaveF]

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?

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

[alexrossi]

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?

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

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?

[DaveF]

...reaching the destination when being able of opening a TCP socket with the last peer?

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

[Wind_FURY]

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

The world’s first dual-funded mainnet Lightning Network channel was opened last week in block 681,753 on the Bitcoin mainnet. Blockstream used its c-lightning implementation of the Lightning Network protocol to open the channel and announced it via a blog post.

A dual-funded Lightning channel allows both participant nodes to contribute to the channel’s opening transaction. It is unique because, up to this point, only the Lightning node that initiated the channel opening was able to add funds to the funding transaction.

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.

[fxsniper]

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?

[Carlton Banks]

how many used one of the "lightning in a box" implementations.

Not that it matters that much, but all the pre-done ones that I know of are running LND so over time C-lightning could wind up being a much smaller player.
I like the C-lightning plugins idea, but LND seems to be more widely used.

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

[BlackHatCoiner]

Lightning Network for use with bitcoin only right?

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)

Can Lightning Network use with other alt coin?

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.

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

The Lightning Network is a protocol, not a token.

[DooMAD]

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

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.

[d5000]

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

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.

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

[Rath_]

-snip

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?

[Carlton Banks]

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.

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

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

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.

[DaveF]

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

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.

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

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.

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

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.

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

[Carlton Banks]

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

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.

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.

[Rath_]

with a fully-fledged server, you can run multiple lightning instances anyway.

I am aware of that. I am already running a bunch of virtual machines on that server so I would rather not waste any resources, especially RAM.

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

Sounds good, but an UPS would be an overkill for the amount of BTC that I want to lock up on the LN.

wait till version 0.10.1, or compile/run master branch, the spec for dual fund has slightly changed.

I compiled c-lightning yesterday on my own without specifying the target version, so I guess that I am running a fairly recent version of the master branch. lightning-cli getinfo returns version: v0.10.0-162-g33736b8

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.

Thanks Dave! The mempool is slowly clearing up, so I would appreciate if you could do it in your spare time. By the way, are you going to open any more channels in the near future? I would like to maintain channels with a few forum members but it would nice to improve my node's connectivity this way.

[DaveF]

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.

Thanks Dave! The mempool is slowly clearing up, so I would appreciate if you could do it in your spare time. By the way, are you going to open any more channels in the near future? I would like to maintain channels with a few forum members but it would nice to improve my node's connectivity this way.

We are in the process of moving out of our data-centers to one central one AND at the same time moving office space, so the only machines I can run my lightning stuff on are my own server and workstation. For the C-lightning node that I have I need to spin down some VMs and copy them elsewhere to make RAM & CPU available for it.

If you want to peer and keep a channel open in general I just made an on chain TX to my main node running LND @ 15 sat /b so it should clear overnight you can peer to it at
0345e4b0a36a5dc56450421637555bf7dc3025b59db78501609b78a7c187d8b346@bajjf27ngq6266p7ol6a36yziuajxedm434z3b4r54aybabqlqofkead.onion:9735

Once I have the other node updated and synced I'll let you know.

-Dave