pull down to refresh

I'm looking to start building on Lightning and trying to wrap my head around where to start. I figured I would start by running a Lightning node and get super familiar with the RPC calls and such. But not sure which implementation I should become familiar with first: CLN or LND. Anyone have opinions for this newbie?
LND is probably the most "robust" in terms of features. it has a built-in REST and gRPC API. so if you plan on building on it, it would be a good choice. it also has alot of good services that are built on top of it already that you can point at your node to get extra features and stuff. that said, it's back by lightning labs who tend to prioritize what features they need for their business instead of the network itself. not necessarily a bad thing. just something to know.
CLN is also a good option. it's backed by a company that does tend seem to care more about the community. the implementation is in a language that's harder to understand IMO. everything is a plugin, which is a blessing and a curse. this includes the gRPC API. the REST API is actually a separate project implemented as a plugin. this is needed if you want to connect it to something like Zeus so you can manage it on your phone. it has more of a feel of being in development and still being hacked on. it's a solid implementation for sure, but still has some rough edges to be aware of.
depending on your experience and technical know-how, i'd recommend LND for more of a beginner or if you just wanna get something setup. CLN is great if you wanna explore building things on top of the lightning network because their plugin system makes it super easy.
reply
This is very helpful. For CLN, there seem to be multiple ways to request data from the node: sparko and c-lightning-REST being two I know about. I read somewhere there's a new way to request data that isn't either of these but can't remember what it is.
Which is the preferred library used these days to make calls to the node?
reply
Wow! Great explanation cleared my basics.
reply
reply
reply
I was under the impression that most people use LND or CLN. Would you prefer Eclair over both of them?
reply
Already and asked and answered here #77038
reply
Ah, thanks!
reply
CLN if you just want lightning. LND if you want to play around with stuff like LNbits and other software like that.
reply
LNBits supports CLN too.
reply
Super noob question: LNbits says it's an Accounts System but what is an account as it relates to lightning nodes. Are channels associated to accounts? It it just a way of managing groups of channels?
reply
The node is the bank full of channels with liquidity. LNbits can make lightning wallets that can use the liquidity in those channels. If someone sends you btc to that wallet with lightning, you are basically getting a promise that those sats are yours from the liquidity in the channels.
reply
Ahhh, makes sense. Thank you!
reply
Thanks for this. So LND has more of an ecosystem built around it?
reply
The node is the bank full of channels with liquidity. LNbits can make lightning wallets that can use the liquidity in those channels. If someone sends you btc to that wallet with lightning, you are basically getting a promise that those sats are yours from the liquidity in the channels.
reply
shit i replied to the wrong comment
reply
LND is pretty crappy, we have been working with it and encountered insane bugs involving configuration and environment variables handling. Completely inexcusable ones. The workarounds so far appear to require setting configurations directly in the commandline. But the documentation is definitely better. I'm using LND in my work because it's written in Go, but I encountered also inexcusable glitches involving Go modules (just check out the version of the latest version recognised on the go.dev documentation site, v0.0.2).
Aside from these LND is probably a little easier to work with for a beginner, just, not if you were hoping to import things from it into your own Go code. I attempted to solve an issue relating to eliminating the masses of imports triggered by importing its gRPC/Protobuf generated code, and wound up just writing a small script that let me snapshot a version at a tag, eliminating all the documentation fluff and retargeting the internal imports to the new Git URL for it.
CLN seems to be a lot better written, but by the nature of the C language has more chance of having far less obvious and more damaging vulnerabilities involving buffer overflows, stack smashing attacks and memory leaks. I've not checked out their documentation, it might be good too. Certainly it very likely is more memory efficient but may not translate to lower latency for high load, since Go's runtime focuses on that performance metric.
reply
Out of curiosity, do you know if anyone is working on a Rust implementation?
reply
There is a sample client written with LDK.
reply
Yes. Don't hear much about it though. https://github.com/lightningdevkit/rust-lightning
reply
Oh cool, thanks!
reply
isn't LDK written in rust? Or at least uses a Rust lightning implementation https://github.com/lightningdevkit/rust-lightning
reply
I thought LDK was a set of utilities to interact with a lightning node, rather than an implementation of a node 🤔
reply
It's a set of libraries in Rust for that purpose, but as another poster just above mentions, there is a project, and according to the readme, is fully functional and implements all the BOLTs.
It's funny, I am always seeing so much noise from the Rust dev community about how great their stuff is yet rust-lightning has less press than any other implementation.
I personally am dirty on Rust due to it being sponsored by Bitcoin DID-denying Mozilla Foundation (because boiling the oceans!). As well as the fact that the only thing about the language that is any better than C++ is the build system (cargo), which basically is a copy of the Go build system with inline generators. (and sadly too many Go devs use Make to trigger these things and then get carried away with themselves ignoring all the other things the Go tooling does). Actually, I'm pretty dirty on most Go based projects too, in the Bitcoin ecosystem, seems to me like none of them really love Go that much, building and writing like C++ programmers. Cosmos ecosystem pissed me off too, because they write Go like Java programmers.
Gah, doesn't anyone read the f...king vast repository of great advice on how to build Go stuff other than hardcore gophers like me???
edit: no, rust-lightning is not a server implementation, for that look for Sensei https://l2.technology/sensei
reply
I'm no Rust expert but I find it a joy to work with. That being said, I come from a mostly Javascript/Typescript background and not used to having a compiler be so helpful at preventing runtime exceptions.
I don't have much experience with Go, but I've heard mostly good things about it.
reply
AFAIU, LDK’s main target audience are wallet providers that want to add lightning functionality to their existing wallet software. In that situation, LDK handles all interactions with the Lightning Network, but the wallet developers need to bring-their-own-blockchain (e.g. Bitcoin Core) and need to handle their on-chain transactions themselves.
If you just want to run a Lightning Node, I don’t think that LDK by itself is what you are looking for.
reply
Alright, cool, that makes sense. Thanks!
reply
This is very helpful. Thanks for the response!
reply
You'll run CLN and be happy
reply
ha. This is referring to the LND bug, right? Again, super new to lightning, but I remember some drama a few months back - just didn't understand what it was about at the time.
reply
I prefer CLN. But I run both on different machines.
reply
This is probably what I'll end up doing. I'm more curious about which I should use first when building apps to integrate with a lightning node.
reply
Myself and all the bitcoin developers I know run CLN.
reply
I've tried twice now to fire up a personal spending node using CLN and 3x private channels and both times failed. Going to try LND now.
reply
Right decision. CLN is better for developers.
reply
I've experience the same thing today - tried multiple times to open a channel with an LND node and kept getting an error, something about a subdaemon.
reply