Topic: The Lightning Network FAQ - page 29. (Read 33426 times)

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

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.

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

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:



[moderator's note: consecutive posts merged]

not sure the first is (only) tor related:
source: https://github.com/ElementsProject/lightning/blob/5c38e5a08fbf15cc4a7e31ef1a017b580b11a4c6/plugins/libplugin-pay.c#L1250

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.


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

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.

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


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


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

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

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


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

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

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


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 

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

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

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

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

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.

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.

Neither Zap for PC nore Eclair for Android have any mechanism to change the fees collected.  Zap you can set an upper limit for fees paid on out bound (presumably from yourself) while Eclair you can set a satoshi per kb on the block-chain transactions, but not for Lightning.


I know one node does have two nodes (one each clear and onion) however not all of the nodes I currently have are particularly large.

To inspire another member to do some work for you (in the event that s/he does not know the answer right of the top of his/her head), maybe you could explain some efforts (work) that you have already attempted in this matter, and maybe even through such efforts, you would end up finding the information that you are seeking and further be able to provide that information to the rest of us who are following this thread?  

Wow a hypothetical way to actually contribute value!!! rather than appearing as someone who merely is striving to cause work upon others.