Skip to main content

What Implementation Should I Run?

We're got our drives installed, a ZFS mirror created, and now we're about ready to start setting up a Node.

We now need to choose an implementation.

Let's back up again and make sure we understand this.

What is an "implementation" again?​

Remember how we talked about the BOLTS?

If you don't remember that, skim this previous page.

The BOLTS are the specification that software developers have to follow if they want to build a Lightning node.

You don't need to memorize the specification or even understand most of it, but I want you to briefly look at a random section of one of the bolts, the section on the Lightning message format.

Again. No need to read that carefully. The important thing is just that you understand what is going on conceptually: There is a very specific "standard" for how a Lightning node should operate, and all the organizations who are creating node software are responsible for "meeting the standard."

Node software that (hopefully) "meets the standard" of the BOLTS is called an implementation.

Among which implementations can I choose?​

Here are the implementations you can choose from:

LND is developed by the well-funded startup Lighting Labs. Most of the big routing nodes on the network are running LND. It's written in the language Go.

CLN / Core Lightning, is developed by Blockstream, the 800-pound-Gorilla of Bitcoin development. Many big nodes use CLN, but not as many as LND. CLN is written in C.

Eclair is developed by the French company ACINQ. As far as I can tell, the only organization that uses Eclair is ACINQ itself. This company also runs the "ACINQ" node, which is connected to the Phoenix Wallet. Eclair is written in the obscure language Scala, just to make everyone else's life more difficult. (And because French developers love Scala, for some unknown reason.)

LDK isn't a node, but more like a toolkit that can be used to make a node. Confused? Don't worry. This really isn't for building "computer-based" nodes -- it's mainly for building node implementations that can run on mobile devices. LDK is written in the language Rust.

So, only two of these implementations are have been widely deployed on the network, and for this reason, you'll also need to choose between LND and CLN (unless you are a super-nerd.)

And after running both and LND and CLN node myself, I'm about to make that choice for you.

Why you should run LND for your first node​

LND has the best documentation​

LND has the best documentation for new developers. CLN's documentation is good, but really is best for developers who already understand Lightning, and preferably already are conversant in the "C" language. Here is an example from CLN's documentation. I'll quote:

To convert above hex back into the binary hsm_secret (32 bytes format) for recovery, you can re-enter the hexdump into a text file and use xxd:

cat > hsm_secret_hex.txt <<HEX
00: 30cc f221 94e1 7f01 cd54 d68c a1ba f124
10: e1f3 1d45 d904 823c 77b7 1e18 fd93 1676
HEX
xxd -r hsm_secret_hex.txt > hsm_secret
chmod 0400 hsm_secret

How are your hexdump skills?

Mine are pretty bad!

Also -- if you are a "typical" developer, maybe someone who is good with Python, Javascript, Ruby, or other friendly language, there is a good chance you've never had to deal with anything like hexdump in the past.

On the other hand, you can start at the beginning with LND's documentation, and while it's definitely not "simple", it is at least reasonably easy to understand.

LND has the biggest market share​

Among nodes run on computers (as opposed to say, mobile phones), most estimates put the dominance of LND at about 80%. If you run LND, you therefore get a few benefits

  • Most of the educational material and other tutorials is written for LND
  • Most of tools that you could run on top of your node are made for LND

Because LND has the biggest market share, you might encounter fewer problems​

As we will discuss, currently the most problematic technical issue on the Lightning Network is complex and sometimes unexpected behavior that emerges when a node tries to CLOSE a channel.

When a channel is closed between two nodes, the nodes need to talk to each other and agree on a few complicated things.

We'll provide details on this issue in our section about channel closures, but for our purposes here, you should know that in some cases this "discussion between nodes" is more likely to fail (or reach an unsatisfactory outcome), in the case that the two nodes use DIFFERENT implementations.

Put another way: A "channel close" operation shared between two LND nodes sometimes goes more smoothly than a "channel close" operation shared between a CLN and an LND node.

Why you might want to try CLN for your NEXT node​

I recommend for your first node that you run LND, but for your node #2, after you have LND up and running, you should try C-Lightning. C-Lighting has interesting qualities:

  • Supposedly, since it is written in C, CLN might be more processor-efficient than LND. But, if you're planning on running your node on a computer, we already decided you were going to have at least 8x CPU, right? In my experience, even with hundreds of channels, LND is quite well-behaved and never uses unexpectedly big amounts of RAM or CPU...
  • CLN has a robust plugin architecture. If you are developing an application that needs to run "along-side" a node, CLN is well-known for working well with other applications.
  • This paragraph may soon be out-of-date, but as of April 2024, CLN has support for a few important experimental features not yet implemented by LND: Namely splicing and bolt12 offers. Of course, as long as LND doesn't support them, neither of these features can be widely used on the Network.

For the rest of this guide, we are setting up an LND node​

You can do similar steps with CLN, but trying to set both a LND and CLN node at the same time, will be to complicated.

Going forward we are assuming you will proceed with LND.

Last updated on