Trying to navigate the different Lightning implementations can be a challenge. Although there were initially three implementations: c-lightning, eclair and lnd, more continue to come out of the woodwork all the time with ptarmigan, rust-lightning and Electrum the most recent to enter the fray.
Often, it seems developers and aspiring developers choose to use or contribute to a particular implementation based on the language it is written in. Familiar with Scala? Choose eclair. Excited by the potential of Rust? Choose rust-lightning. However, there are other key considerations such as the aims, design philosophies, use cases and trade offs of the different implementations. In addition, just because an implementation is written in a certain language doesn’t necessarily mean that you are required to code in that language to contribute to the ecosystem around that implementation.
The emerging contrasts between the lnd and rust-lightning implementations were explored on a panel at Breaking Bitcoin 2019 and in this Bitcoin Magazine article. Whilst lnd seeks to take the load off developers and provide ultimate functionality out of the box, rust-lightning seeks to offer ultimate flexibility with developers encouraged to bring their own components and slot them in.
In contrast, c-lightning offers a third way. It maintains a robust and secure core that is designed to not be tweaked or replaced by the developer. Flexibility and additional functionality is available through the use of plugins that can be written by the developer in various languages such as Python or Go. The aim is for the c-lightning ecosystem to emerge as a testbed for experimenting with new cutting edge features, previously the terrain of other implementations such as lnd and eclair, without sacrificing the performance and robustness of the core.
Plugins are subprocesses that are started by the main lightningd daemon. They work in cooperation with lightningd. Any plugins that are surplus to…