CLN, previously c-lightning, has been in production use on the Bitcoin mainnet since early 2018.
CLN only works on Linux and MacOS, and requires a local or remote bitcoind version 0.16 or above that is fully caught up with the network that the user is running on and relays transactions from.
“We are built from the Lightning BOLT specifications, literally!” Russel told Bitcoin Magazine. “This means we care a great deal (and, as a team, have put a huge amount of effort) into coordinating the architecture of the entire Lightning Network via the BOLT specifications.”
“Part of the reason we do the spec-and-review-across-implementations process is that it helps identify better ways of doing things — find bugs, identify future problems,” Lisa Neigut, Lightning protocol engineer at Blockstream, told Bitcoin Magazine.
Given its efficiency and lightweight footprint, CLN is likely the best-suited implementation for low-specification devices.
BOLT 12 is another draft specification for Lightning wallets and nodes with experimental support in CLN. The proposed feature, coined “offers,” would improve upon BOLT 11 invoices by enabling reusable offers, whereas a BOLT 11 invoice can only be used once. Furthermore, while an invoice is exclusively a payment request, you can use an offer to also send, not only receive, money.
[Lightning Labs'] LND has seen the largest community involvement among all implementations and currently runs the majority of all network nodes. Some estimates put LND’s share of total public Lightning nodes anywhere between 70% and 90%.
LND also boasts what is arguably the largest full-time development team. As a result, the team has managed to build a plethora of value-added services around LND, such as Aperture and the liquidity services Lightning Loop and Pool.
“The Labs team has come up with great stuff,” Neigut said. “They just, as an organization, haven’t been amazing about writing specs for the things that they add. A good example of that is KeySend.”
“They launched it, a lot of people started using it, but they never fully specified it,” Neigut added. “So CLN wanted to be able to support it. One of our team members had to go back through and figure out how to make it work just by reading their code and reverse engineering it.”
A spec eventually got written by Spiral’s Lightning implementation, LDK, Neigut recalled, after its team reverse-engineered Lightning Labs’ code.
Russel said [....] “I genuinely believe they will find a way of both creating a sustainable income stream and being a reliable partner in the technical development of the Lightning Network; I don’t think anyone wants to see the network split into pieces.”
Blockstream’s move to push CLN as a spec-compliant, modular and lightweight offering comes as an alternative for those interested in running a node implementation that strives to be completely interoperable with the rest of the network and provides a unique set of benefits to those who do.
As different implementations strive to become their best version and cater to a specific use case by exploring their own value proposition, the user is ultimately the one to benefit as greater and better options emerge.
#CLN Fact of the Day: Protocol changes which haven't been finalized in the spec are only enabled with --enable-experimental-features builds, or with explicit 'experimental-' options. These don't get deprecation guarantees and can change at any time, so extra #reckless!
reply
There was another recent article on LN in Bitcoin Magazine of interest.
How Bitcoin’s Leading Lightning Implementations Are Expanding Functionality | Bitcoin Magazine #20529 https://bitcoinmagazine.com/technical/bitcoin-lightning-network-expanding-function
reply
Also see:
What Implementation of Bitcoin’s Lightning Network Should You Pick? | Bitcoin Magazine #18556 https://bitcoinmagazine.com/technical/tradeoffs-of-bitcoin-lightning-implementations
reply