The Lightning Network FAQ

[Rath_]

Neither Zap for PC nore Eclair for Android have any mechanism to change the fees collected.

I don't think that Eclair Mobile has ever been capable of routing payments. I believe that it creates only private channels. You would be required to keep the app active in the background all the time. Your available balance might have been slightly shifting because new commitment transactions with different fees are signed periodically. The founder of the channel always pays the closing fee so that's why it's deducted from your balance.

As for the Zap, you can actually download and run lncli to manage the built-in LND node. See this guide. Once you have installed it, you should be able to use lncli updatechanpolicy command to modify the fee policy of your every channel.

[1714141391]

1714141391

[1714141391]

1714141391

[1714141391]

1714141391

[1714141391]

1714141391

[1714141391]

1714141391

[Timelord2067]

As for the Zap, you can actually download and run lncli to manage the built-in LND node. See this guide. Once you have installed it, you should be able to use lncli updatechanpolicy command to modify the fee policy of your every channel.

Thanks for the suggestion, I'll have a look and see if I can get it working, otherwise, I'll just slowly empty the funds to enable me to have inbound capacity on those apps with just a nominal amount left in reserve for a rainy day.

[n0nce]

As for the Zap, you can actually download and run lncli to manage the built-in LND node. See this guide. Once you have installed it, you should be able to use lncli updatechanpolicy command to modify the fee policy of your every channel.

Thanks for the suggestion, I'll have a look and see if I can get it working, otherwise, I'll just slowly empty the funds to enable me to have inbound capacity on those apps with just a nominal amount left in reserve for a rainy day.

If you want to be a Lightning router, I would highly suggest installing a dedicated machine in your network running Linux and c-lightning or lnd.

Opening channels between two already connected (large) nodes makes little sense, so try creating new connections that don't already exist. It's also a lot of trial and error; there's no perfect recipe on how to create the perfect channels. If you see no traffic over a link for a while, close it and open another etc.

You also may want to explore if the nodes that you'd like to connect through you already have (direct or indirect) connections via Lightning explorers like https://amboss.space/ or https://1ml.com/.

[Timelord2067]

I wouldn't say I "want" to be a Lightning Router, rather, after I'd installed those apps (on my PC and Android phone) I saw there was activity, now there is none and I was wondering if there might be an error in the app or network.

Now I can see the activity I once had was more by fluke than anything (and no, I'm not connected to overly large nodes, but by the same token I'm not connected to the same nodes I once was).

[BlackHatCoiner]

Found some cool creations; sharing!

The Quickening — Bitcoin Lightning Network PoS Terminal (<$8)
https://github.com/arcbtc/Quickening

LNURLPoS — Cheap, offline(!), DIY bitcoin lightning-network PoS
https://github.com/arcbtc/LNURLPoS

[darkv0rt3x]

Found some cool creations; sharing!

The Quickening — Bitcoin Lightning Network PoS Terminal (<$8)
https://github.com/arcbtc/Quickening

LNURLPoS — Cheap, offline(!), DIY bitcoin lightning-network PoS
https://github.com/arcbtc/LNURLPoS

Check this too
https://twitter.com/arcbtc/status/1443933320056823809

[Rizzrack]

... Where is the post where the "Lightning network" was first proposed on this forum?

Sounded like a weird question at first but got me wondering... Seems that Mike Hearn pointed to this thread : Instant TX for established business relationships (need replacements/nLockTime) as the Lighning Network's primordial forum soup

What is the Lightning Network? It is the latest name for an old idea: to use payment channels between various low-trust intermediaries in order to transmit payments

https://blog.plan99.net/the-capacity-cliff-586d1bf7715e

So I decided to put together an umbel box to compare it to raspiblitz / mynode

I fired up an umbrel node also. Took ~4days for sync but after this it does not display the info properly...


Only had a 500GB SSD around so I assume that might be the issue. It still has 24GB available though. Will retry with a 1TB as soon as I get my hands on one 

[psycodad]

I get about as much failed transactions as successful ones on my node.

Does anybody know how I can further investigate the reason for failed transactions (RTL just says "failed" as status) ?

[Rath_]

I get about as much failed transactions as successful ones on my node.

It's completely normal. I have successfully routed 84 transactions and I have 357 failed ones.

Does anybody know how I can further investigate the reason for failed transactions (RTL just says "failed" as status) ?

"Failed" means that the transaction failed at some further point in the route. If your node fails to route a payment then you will see "Local_failed" instead. You can't really do much about it. If you see a lot of 10, 10k, 100k sat failed payments then someone is very likely probing your channels. It can be done with any other amount as well.

[DaveF]

I fired up an umbrel node also. Took ~4days for sync but after this it does not display the info properly...


Only had a 500GB SSD around so I assume that might be the issue. It still has 24GB available though. Will retry with a 1TB as soon as I get my hands on one 

When it's all done you need more then 500GB, between the blockchain, the LN database and the Electrum DB:
A 1TB will be fine for a long time to come, but 500 GB is just not going to work with everything.
You might be able just to shut it down and clone the 500GB to a 1TB but I would just let it resync.



-Dave

[psycodad]

I get about as much failed transactions as successful ones on my node.

It's completely normal. I have successfully routed 84 transactions and I have 357 failed transactions.

Thanks for your reply and explanation, that's comforting to know, I first thought I'd possibly stuck my fat fingers too deep into the thing at some point

Does anybody know how I can further investigate the reason for failed transactions (RTL just says "failed" as status) ?

"Failed" means that the transaction failed at some further point in the route. If your node fails to route a payment then you will see "Local_failed" instead. You can't really do much about it. If you see a lot of 10, 10k, 100k sat failed payments then someone is very likely probing your channels. It can be done with any other amount as well.

Checking further, I saw that I also have a few "Local Failed" transactions.
But I am still wondering what would make a transaction fail. I played around a bit with the "getroute" rpc command and I was under the impression that querying a route given a certain amount to transfer will only return channels that have the respective capacity/liquidity to route this payment. Is this wrong? Does getroute not know the capacity/liquidity of channels in transit?
Or what other reasons can make a transaction fail (locally or remote)?

[Rath_]

Does getroute not know the capacity/liquidity of channels in transit?

No, liquidity is not advertised across the network. That would be a privacy infringement. It knows the total channel capacity, though.

Or what other reasons can make a transaction fail (locally or remote)?

Locally: Check out this comment. There are apparently five possible causes. lightning-cli listforwards returns the exact error if a transaction fails locally.

Remotely: Some node might fail a transaction locally or suddenly go offline. There might be some other causes that I am not aware of at the moment too.

[psycodad]

Does getroute not know the capacity/liquidity of channels in transit?

No, liquidity is not advertised across the network. That would be a privacy infringement. It knows the total channel capacity, though.

Makes perfect sense, I confused capacity with current liquidity.
Otherwise it would be possible to see which channels are used or not by taking snapshots of the liquidity balance from them. My thinking error.

Or what other reasons can make a transaction fail (locally or remote)?

Locally: Check out this comment. There are apparently five possible causes. lightning-cli listforwards returns the exact error if a transaction fails locally.

Remotely: Some node might fail a transaction locally or suddenly go offline. There might be some other causes that I am not aware of at the moment too.

Thanks, funny enough the two errors I get locally are not listed there:

Code:

"failreason": "WIRE_TEMPORARY_CHANNEL_FAILURE",
"failreason": "WIRE_REQUIRED_NODE_FEATURE_MISSING",

From grepping the sources I conclude these are both related to tor connections in some way.
The first seems to be nodes down the routing path being unreachable and the second I do not understand completely yet but it seems related to a disagreement of nodes regarding some HTLC parameters.
Will keep reading the debug.log around successful and failed transactions to try to get a better understanding on what exactly happens under the hood.

[ndalliard]

Code:

"failreason": "WIRE_TEMPORARY_CHANNEL_FAILURE",
"failreason": "WIRE_REQUIRED_NODE_FEATURE_MISSING",

From grepping the sources I conclude these are both related to tor connections in some way.
The first seems to be nodes down the routing path being unreachable and the second I do not understand completely yet but it seems related to a disagreement of nodes regarding some HTLC parameters.
Will keep reading the debug.log around successful and failed transactions to try to get a better understanding on what exactly happens under the hood.

not sure the first is (only) tor related:

Code:

	case WIRE_TEMPORARY_CHANNEL_FAILURE: {
		/* These are an indication that the capacity was insufficient,
		 * remember the amount we tried as an estimate. */

source: https://github.com/ElementsProject/lightning/blob/5c38e5a08fbf15cc4a7e31ef1a017b580b11a4c6/plugins/libplugin-pay.c#L1250

[psycodad]

not sure the first is (only) tor related:

Code:

	case WIRE_TEMPORARY_CHANNEL_FAILURE: {
		/* These are an indication that the capacity was insufficient,
		 * remember the amount we tried as an estimate. */

source: https://github.com/ElementsProject/lightning/blob/5c38e5a08fbf15cc4a7e31ef1a017b580b11a4c6/plugins/libplugin-pay.c#L1250

I stand corrected, I misread that into the onion_ files that popped up first from my grep, overlooking the libplugin-pay.c.





Reposting this from WO thread here as heads-up:

Lightning node operators need to patch some vulnerabilities ... now 

https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003264.html

> The vulnerabilities are expected to be patched in:
> * Eclair: v0.6.2+ (CVE-2021-41591)
> * LND: v0.13.3+ (CVE-2021-41592)
> * LDK: v0.0.102 (not released as production software yet)

* C-lightning v0.10.2 (CVE-2021-41593)

[moderator's note: consecutive posts merged]

[darkv0rt3x]

Hi...

I just watched a video and I would like to know opinions on it.

https://www.youtube.com/watch?v=yGrUOLsC9cw

I don't exactly agree when the guy says raspberry Pis and laptops (or other devices, like mine, RP64) don't have enough processing power to deal with so much data!
I'm not a computer scientist or anything, but if these machines would struggle with the amount of data they need to process, I think these devices would easily heat up constantly and I think think that's the case in 95% or more of the cases.

Then he also mentions that another problem with the network is that there are channels opening and closing, therefore, path finding algos many times can't find paths for the payments because of this constant change in the network. And says the same with respect to balances of channels are also changing constantly.

Well, my argument here is that, yes, it is true that there are many channels opening and closing and yes there is balance updates every second, etc. Regarding the first part, I don't know how can he say such thing without backing up his statement without any data, like some plots of channels opened and closed per hour, for instance or how can he says that balance updates in channels is a problem when balance updates is something inherent to the network itself, probably at the protocol level... I'm not sure if this guy has anything at all to backup what he claims.

The guy quotes Rusty Russel on a post he wrote like 4 years ago on Reddit. I'm interest knowing if there was something done to mitigate the supposed problem...

What are your thoughts???

[n0nce]

~

Unfortunately I don't have much time for YouTube videos, but looking at his upload list it seems it's one of the hillbilly BCH big blockers who still think it's a good idea to scale on-chain, just because it works on their un-used network and they resist development and evolution of the network. If he argues against LN because he thinks it's too hard to run on low-power hardware due to size constraints (I would get processing power, but storage? Really?) he is basically saying his own coin (that needs more space) is not decentraliseable because low-power device can't handle a lot of data. He is then actually arguing against the security of his own preferred coin (BCH it seems).

The use of Go (lnd) can be a concern on low-power hardware in the future, but c-lightning should run easy smooooth and cool on most devices.

So without even watching it, from what you wrote and seeing the video thumbnails & titles, I'd say this guy is clueless.

[ndalliard]

~

like n0nce i won't go into details (although i watched the video)

1. the video is 3 years old. just keep that in mind. a lot happened since then. but you recognized that yourself, mentioning the quote from rusty which is 4 years old
2. towards the end of the video, he says something like:

every attempt to raising the blocksize in the last several years have all been shutdown immediately

which obviously is wrong, the blocksize was increased with segwit
3. looking at the other videos on the channel, that guy is/was clearly on the wrong site of history

mostly ad hominem, i know, but sometimes i don't have the time for more...  

[Rizzrack]

one of the hillbilly BCH big blockers who still think it's a good idea to scale on-chain...

Sorry for the OT but was reading the latest posts and when I saw yours it reminded me of something:

https://twitter.com/ElectrumSV/status/1445091823215464452?s=20

[darkv0rt3x]

~

Unfortunately I don't have much time for YouTube videos, but looking at his upload list it seems it's one of the hillbilly BCH big blockers who still think it's a good idea to scale on-chain, just because it works on their un-used network and they resist development and evolution of the network. If he argues against LN because he thinks it's too hard to run on low-power hardware due to size constraints (I would get processing power, but storage? Really?) he is basically saying his own coin (that needs more space) is not decentraliseable because low-power device can't handle a lot of data. He is then actually arguing against the security of his own preferred coin (BCH it seems).

The use of Go (lnd) can be a concern on low-power hardware in the future, but c-lightning should run easy smooooth and cool on most devices.

So without even watching it, from what you wrote and seeing the video thumbnails & titles, I'd say this guy is clueless.

I understand. Many people don't like youtube videos. But, at least me, I can't deny that there is smart people everywhere, so watching other opinions, no matter if in youtube, facebook or reddit or whatever, is not a reason to say it's not valid thoughts of those people. And when we read/watch/whatever other opinions, we also open our own horizons.

Anyway, c-lightning, mostly being written in C, I think the same way you think about running in low power devices but still, it's not the application code itself that may put some stress on the hardware, is what that code "tells" the hardware to do in terms of data processing.

I didn't even knew but some people on Blockstream started a project to simulate, test and improve path finding algorithms  using a large test Lightning network with an accurate topology extrapolated from the current topolgy with 1 millions channels. You guys can check it on Rusty Russel github here: https://github.com/rustyrussell/million-channels-project

There is also this post on medium from Rusty Russel talking about the supposed issue, here:
https://medium.com/blockstream/letting-a-million-channels-bloom-985bdb28660b

So, I'm just glad this claims were settled and we can rest assured that LN will be able to overcome any possible issues.

~

like n0nce i won't go into details (although i watched the video)

1. the video is 3 years old. just keep that in mind. a lot happened since then. but you recognized that yourself, mentioning the quote from rusty which is 4 years old
2. towards the end of the video, he says something like:

every attempt to raising the blocksize in the last several years have all been shutdown immediately

which obviously is wrong, the blocksize was increased with segwit
3. looking at the other videos on the channel, that guy is/was clearly on the wrong site of history

mostly ad hominem, i know, but sometimes i don't have the time for more... 

Yeah, I understand that it is 3 or 4 years old.
This guy was clearly trying to create fear on the LN or something. But yes, he's (or at least was) completely on the wrong side when he says that the attempts to increase the block size were immediately shut down. This says we would agree with it, completely ignoring the consequences of that regarding centralization, storage issues, etc. And, yes, segwit did it and more, in a very clever way, no doubts about it.