Topic: The Lightning Network FAQ - page 31. (Read 32079 times)

Interesting - since it was mentioned in this thread that lnd pulls way more on the resources than c-lightning, maybe it's worth a try with c-lightning?

Oh damn. Yeah I'm not kidding when I say with a Pi (model 3 though) it took me weeks for the IBD!

With all these issues, I'm wondering why even so many people bother with SBCs then. I mean for nodes. They're great to put on / in a robot or other embedded environment, but a new Pi Model 4 with 8GB RAM and 1TB SSD + case and PSU runs about 200 bucks from the top of my head.

You should easily be able to get a used laptop or Intel NUC with 8GB RAM, 1TB SSD and much more power (and thus quieter at the same load) for ~200.
It's also cleaner than a RPi with external drive dangling around and you get a screen and keyboard 'for free'

I personally use an old laptop with broken keyboard and partially broken screen, but it was free (someone wanted to throw it away) and runs very nicely after I reapplied thermal paste, installed a fresh Debian OS + installed a larger HDD. I also modded the fan to run off a 5V rail at continuous speed instead of ramping up and down all the time. The nice thing is the battery is still good for a bunch of time, so I can unplug it to move it around and when the power cuts out it remains up. Built-in 'UPS'.

I was running LND on the Pi. I don't think it matters; It would have been hot with c-lightning as well. I don't remember how much CPU LND was using on average. I believe that bitcoind was stressing it the most.


I bought a 1 TB Sandisk Extreme USB SSD. I am still using it in my current build (I didn't want to spend any extra money on another internal drive) and it seems to be working as well as other SATA SSDs.

I also tried running ElectrumX on the Pi but I couldn't stand the noise of the fan which started kicking in even more frequently. The initial sync was taking so long that I eventually gave up.

Oh, now that you mention channel opening: an issue that has been very annoying for me a few times already, is that I can't have multiple channels with another peer. I'm sure it's more clean and more c-style to have 1 larger channel instead of 2 small channels, but there are situations where you'd rather add another channel instead of closing and re-opening for example. No idea why exactly it's not possible in c-lightning, but annoying from a day-to-day user perspective imho.

That's good to know. So it was hot with c-lightning or lnd? And did you then use an external SSD or how did you manage the storage?

Yup, thanks for including that info! Will probably be the first big "LN FAQ" that actually tells people to "just get a larger drive" XD Since it's honestly a pain with pruned, and maybe worked in the past or something but tons of users run into issues with it lately.

I have been using c-lightning for quite some time now and I am really satisfied with it. I am not a developer, though. All I care about is stability and some useful features. I really like that you can easily open multiple channels via a single command (unlike LND which I believe requires user to construct a transaction manually using PSBTs). We have been also experimenting with dual-funding here.

I ran into some problems with macaroons while using LND. It's been a long time ago so I can't give you the exact details.


I also used that case (without the m.2 slot) for my build. Nevertheless, the Pi was getting quite hot very often despite the built-in fan and included thermal pads. Also, the fan is a little bit noisy above 50% of its maximum speed. I eventually moved my node from the Pi to a normal server.


Thanks! As you already know, I am working on the update of the first post. I will make sure to include this piece of information.

Alright, sounds good! Then maybe I'll buy a Pi 4, SSD etc. as well and build one more node, eh, every additional node helps!

Oh damn, thanks for digging that out for me, must have missed it. I was also under the impression that they encourage to 'use it for more than just full node + miner' but then maybe better not to touch it, indeed.
One idea might be to run lnd within a Docker container. That shouldn't affect the Apollo since it's kind of capsuled in its container, I guess - finally a scenario where Docker might actually make sense. Let's see... Not sure yet.

So far so good, I have been so busy at the office beyond the initial install and adding some BTC and opening some channels I have not done a lot of testing.
I have used RPi and raspiblitz before so other then the case / drive type change it's all the same so I don't think there will be any issues.




The problem is that they may or may not rely on some package that is different then what you need for what you want. Update the wrong thing and.....
Although they do say you can install other packages and even encourage it. It still worries me that if what I need to run has a dependency that is slightly newer / older then what is on the unit it can cause an issue.
They say it's only system level changes but still would rather not have to worry about it. That's just me you may have more free time to shrug it off and start fresh.

-Dave

That's good to know! With RPi 4, correct? How was the experience so far?

What do you mean? I mean the SBC is some Orange Pi or one of those 'Raspberry clones' that have more power, but still a regular old ARM mini SBC. How would it prevent me from SSH'ing into it and installing c-lightning for example?
I know, 512GB is quite limited, worst case I'd in the future replace the SSD, it's a normal m.2 (NVMe afaik).

Yup, I'm aware of that, but worst case I could take out an m.2 SATA SSD from my workstation and replace it with something better (should probably do that anyway )

I have a Argon One m.2 sitting on my desk running a node in a box (raspiblitz)

The Apollo is good, but keep in mind that it's a custom build, so unless something has changed in the last few weeks, you can't just update it, you have to wait for futurebit to release an OS / whatever update. And it's only a 512 GB drive so not a lot of room there for other stuff once you have the full node running.

Remember that the m.2 for the argon is SATA NOT NVMe for the m.2 slot so you have a much smaller choice of what drives you can use. AND the ssd m.2 are getting harder to find.

-Dave

It's not just the processing power. Everything is nowadays written for RPi 4. So with $20 extra, you're also included into implementations of projects that have more support. I could have an issue with my RPi 3, but if you've never used it, you'll just recommend me to buy the latest Pi.

Running a full node on a RPi does, indeed, have this downside. 

I wanted to try some different implementations of Bitcoin node OS, but they'll all take around 2-3 months to complete...

Wow, I knew that each consecutive Pi added a bit more power, but never checked the numbers, and indeed the jump from 3 to 4 is insane!
I always had the issue though, that I bought a Raspberry Pi shortly before the new one came out, so I'm stuck with a 3B+ for almost as long as the model 4 exists.. Ugh. Now I don't want to make the same mistake again and buy a model 4 now if maybe next month a 5 comes out lol.

Anyway, my Bitcoin stuff just runs on an older Intel platform, which is probably still faster than a Pi model 4 (though of course much higher power consumption) and I already had it, so it was 'free'. Also easier to work with in general, e.g. apt updates take forever on Pis (at least anything up to including 3B+).

A Pi is though much more compact and easier to tuck away, I was thinking of still getting a model 4 with the Argon One m.2 case (https://thepihut.com/products/argon-one-m-2-raspberry-pi-4-case). However, I'm hopefully getting my Futurebit Apollo soon whose SBC should have even more power than a Raspi, and will try to install Lightning onto that. Would also be a nice compact solution and having a compact full node with LN and a hashboard would be really sick, let's see how it will work out

I cannot stress this enough, get away from the RPi3 in general at this point to do bitcoin stuff.
It will work, but the RPi4 is just a better unit for not much more money.

Since they say a picture is worth 1000 words and I am too lazy to type, the following image from https://magpi.raspberrypi.org/articles/raspberry-pi-4-vs-raspberry-pi-3b-plus
puts in out there perfectly:



All that extra processing power for $20.00 more.
I know that due to the current shortages prices are all over the place, but you can still here in the US get a 4 with 4GB for $50 delivered give or take a few dollars.
A year / 18 months ago it was a different story. Now, just get the 4 IMO.

-Dave

I have no RPi expience, but on my laptop it works well to put blocks on HDD and chainstate on SSD.

The above adjustment made restarting Bitcoin Core much faster. But it wasn't anywhere close to days, just minutes.

I have no idea if this was discussed yet since this thread is damn long, but I would like to mention that I tried c-lightning with a pruned node, since it was mentioned everywhere that it should be possible, then ran into issues. When asking in the community, I was told that indeed those issues were due to me running Bitcoin Core pruned, so I had to go back to square 1 and restart Bitcoin Core in non-pruned mode.

Also PSA for newbies: Raspberry Pi Model 3B+ with a (fast) USB 3.0 HDD takes literal weeks to sync and verify the whole blockchain. Either have a real desktop (maybe also laptop with enough umph) Linux PC with which you can do the initial sync, then plug the drive into the Pi. Or use an SSD. Just wanting to prevent tons of headache

Especially since in case of an issue with the HDD (give it external power!!), when Bitcoin Core has to restart, it has to re-verify a ton of blocks which can easily add a day or two for each crash that you experience.

The issue is that for my last Lightning project, I needed a HTTPS API, and the one I found for c-lightning was c-lightning-REST, written in NodeJS. Maybe I'll code my own in C, but neever enough time. Argh. 

there are (were?) unknown bugs causing lnd to be resource heavy. In principle, it should be as low impact as a lightning client written in C, but not at all in practice

I don't know if the bugs are in the Go runtime/compiler, or in LND itself. When I wrote that comment, neither did anyone at lightning labs
 


actual rust-lightning is not production-ready last I heard.


I don't really get your issue about the language/dependencies for c-lightning plugins; just don't use any plugin you don't like?

Thanks a lot, ndalliard! A poll would be fun, just to get a general idea I had the same impression of a larger lnd user base though.

Yep, that's true, I really like how the implementation teams work together, also joined a "Lightning Specification Meeting" once to see how it's like, very interesting. And surely, diversity helps. But to me, right now, c-lightning (unintuitively) seems less clean than lnd. This might change once I try it, so I'll do that as soon as I find the time, while keeping my existing node up for the time being...

Yeah, that makes sense, however I would have much preferred all plugins to be in C. I mean that's kind of the reason various implementations exist, imagine the next c-lightning plugin to be coded in Go - that would be quite ironic wouldn't it
I myself like Python quite a lot, but wouldn't write a c-lightning plugin in it for sure. Unfortunately one plugin I needed was only available as a NodeJS implementation and that really sucks, I even have to start it manually after a reboot for example due to node (or I did something wrong, no time for further investigation so far).
Like, let's be honest: NodeJS is more bloat than the whole of lnd, so there's no real point of c-lightning if you need a single node plugin for it.

Oh, that's very good to know! My node is based on a repurposed laptop motherboard, the Pi synched way too slowly for my liking and I had it sitting around.. But keeping it in mind! Since I might instead of replacing my old node, instead deploy a second on a Pi....

---

Came here via link from @Rath_, thanks for your insight! I'm now wondering: if lnd is so resource-heavy and Google-based, what about the rust implementation? Rust is supposed to be a c-alternative ("you can write bootloaders in Rust") etc., and focuses more on being resource friendly, as far as I know. Any opinions and experiences in this thread here? As far as I know it's kind of a "Lightning Core" and something is needed around it to have an actual node, didn't look much deeper into it yet though.

welcome n0nce to the c-lightning users, i am one too. if you mean here in the forum i am not sure, we maybe could make a poll for that at one point, but in general lnd seems to be used a lot more and has also the bigger community it seems

pretty much the reasons i also went with c-lightning

also especially because it seems that everyone is using lnd i went with c-lightning, cause i think it is important to have some diversity. i also see that on developer calls, that the 3 (or 4 if you count the rust implementation) implementations help each other to find bugs and be compliant with the rfcs. i just went with the minority (and not eclair cause that is written in java/scala which sounds bloat to me)

because the community / number of developers around c-lightning is much smaller than for lnd, some plugins are rotting away, but i like the fact, that a developer is free to choose his prefered language to write a plugin and is not forced to use go for it. i agree with you, i try to avoid nodejs and i am even hesitant using python in some cases (that might be a little bit extreme on my part)

rath_ switched from lnd to c-lightning - i asked him the following:

i am happy with c-lightning atm and don't feel like switching

---

i stumbled the other day about this github issue for lnd. it seems that lnd doesn't run on 32 bit systems, after the size of the database gets bigger than 1 gb. and the last commenter there mentions that raspbian (used on raspberrypies) is a 32 bit system) - something to keep in mind when you run lightning on a rpi

Hey LN friends, I'm a c-lightning user for around half a year now, and I'm seriously debating about switching to lnd instead. What do you guys think is the cleaner solution? And what is the more commonly used implementation here?
I just hate hacked-together solutions and dirty code, since those are precursors of failed projects in 5-10 years time max.

I personally much prefer C over Go, and I hate Docker. Additionally, I noticed c-lightning was structured in a more minimalistic way for core functinality, with plugins for additional functionalities like HTTPS API etc., whereas in lnd it's all built-in - this to me at first sounds like bloat! Which I also hate! So I naturally went with c-lightning.

However, after a while of using the node and interacting with it, I noticed the plugin interface isn't as clean and bloat-free as I hoped: some plugins require me to install Node JS , they're all written in tons of different languages and often totally unmaintained for years.

So now, I'm thinking to deploy a new node, running lnd and trying to install it without Docker, straight from source.
Interested to hear your opinions and experiences!

As is pretty much everything in LN. So, if we follow the rules by the book, I think we are kind of safe.
I opened a dual funded channel myself with _Rath and I have now my node setup to advertise my available liquidity.

Everything seems fine so far. And if there is no one to use and to be the ones finding bugs and problems, then, we will never evolve.

well, yeah. It's just new is all, any bugs are not currently obvious, but that doesn't mean there aren't bugs. Time helps to be sure(r).