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

note that the Pi CPU can be underclocked in /boot/config.txt.... somewhere, somehow



you can get even more control using open source BIOS, which became available for the RockPro64 recently (check coreboot.org)

About the underline statement, yes there are some issues but there is a solution. I can't tell it because I'm also not aware how to work around it, but I know it is possible. The c-lightning telegram channel is one of the best places to ask how to run a pruned bitcoin node and c-lightning. Sooner or later you'll get the solution.



Let me tell you about another great solution. And if you're willing to spend a bit more and use an NVME M.2 drive, consider a RockPro64 SBC. It's way faster than Raspi4 and it supports the mentioned superfast drives. The downside is one 4Gb of memory, even so, it's way better than Raspi4.

@BlackHatCoiner, this is towards you too.



My experience with my RockPro64 + Samsung NVME M.2 (128Gb) + 1Tb external drive (Western Digital), I don't complain about any fan noise. I am using an old PC RAM fan and a heat dissipator. During the hashing of the entire blockchain, what heat up the most was in fact the NVME drive. The heat sink did it's job along with the small fan.

In my point of view, LND pros is just the fact that you can open a channel towards someone that already opened a channel towards you, but C-Lightning have more pros. Lighter, less resources hungry, more configurable, and yes, the fact that you can write a plugin in pretty much any language, is a must! This is a door wide open for any dev to contribute. I'm amazed how it is not yet filled with people building plugins.

Anyway, I don't want anything else other than my RockPro64 board (raw Debian in it), and I install solely what I want, the way I want and when I want. Full control... Period!


PS:
Actually, there is a plugin to deal with C-Lightning + Bitcoin pruned node. Check here.

Sure, you can give it a try. Although, you will have to install everything manually rather than use some out-of-the-box solution.


I copied the block data from my computer. I didn't want to waste time so I started the sync while I was waiting for all parts to arrive.


Somewhere around one week. The sync was not even halfway through. It took less than a week on different hardware. See this topic.

C'mon no!

I'm waiting to finish the syncing of my node so I can install ElectrumX on it. I gave up on the node OSes, as I want to do it all from linux, command line by line. I was also facing issues with the outgoing connections; sometimes I hadn't even one node connected which was so annoying. Tried umbrel & myNode which left me unsatisfied. I am now trying Raspibolt which is better. (Due to the running from a linux OS)

I remember reading that it took you a lot of time in the past, but forgot how much exactly, so here're my questions for you since we have the same hardware;

• How long did it take to sync your full node?
• How long was it taking to sync the ElectrumX before you give up?

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.