Bitcoin infrastructure company Blockstream recently rebranded its Lightning Network implementation from c-lightning to Core Lightning (CLN) in an attempt to highlight the project’s long-term focus on interoperability and specification work. The initial name, which alluded to the C programming language the implementation is built in, didn’t reflect the company’s actual intent with the project. Now, Core Lightning seeks to reflect the Blockstream implementation’s value proposition. “We hope the refreshed name better communicates CLN’s focus on interoperability, specification work, and the ongoing aim to provide a reference implementation with priority on correctness and robustness,” the company said in a statement. WHY ARE THERE DIFFERENT IMPLEMENTATIONS OF THE LIGHTNING NETWORK? The Lightning Network is an abstracted concept of what is, in fact, many different Lightning channels connected together. Lightning payment channels set the basis of the network as two participants lock up an amount of bitcoin on the Bitcoin network base layer to make quick and cheap off-chain payments among themselves. However, by opening more channels with different participants, payments can then be routed in this “mesh network,” from one participant to the next until a final recipient of a Lightning payment is found. Therefore, the abstraction that is “the Lightning Network” requires different participants to communicate with each other so they can route each other’s payments and enable frictionless interaction. This communication happens between nodes who run the Lightning protocol software and are therefore able to send and receive payments, among other things. Whereas in Bitcoin there is currently a de-facto standard node software, Bitcoin Core, there is more than one type of Lightning node software that is currently popular. As a result, there is a need for a set of documents to dictate how these different types of Lightning nodes — aka “implementations” — can talk to each other. The Basis of Lightning Technology (BOLT) documents define the set of specifications that all Lightning node implementations must adhere to in order to be a stable, compliant participant in the Lightning Network. There are currently 11 BOLT documents that describe everything from how to establish a payment channel and fund it with bitcoin to how one should request a Lightning payment. Naturally, the fact that there are different Lightning implementations also means that there are different offerings available to users, and they can pick whichever software to run based on their specific needs. At a high level, there are four major Lightning implementations, LND, Core Lightning, Eclair and LDK, each geared toward specific use cases. CORE LIGHTNING: BUILT FROM BOLT CLN, previously c-lightning, has been in production use on the Bitcoin mainnet since early 2018. Written in the C programming language, which offers developers a high degree of control over the behavior of their code even at a low level, CLN has a focus on efficiency as well as on providing developers and users with a modular, plugin-based implementation of Bitcoin’s Layer 2 scaling protocol. “We aim to be a high-performance, enterprise-grade, spec-compliant implementation,” Lightning developer at Blockstream, Rusty Russel, told Bitcoin Magazine. “That traditionally means we’re more for high-end users, businesses and developers to build on top of.” 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. Pruning is partially supported. As a lightweight implementation, CLN enables a great level of customization as it allows the user to make it their own and add only the features they want or need. Developers can interface with the daemon through custom JSON-RPC methods, allowing them to efficiently customize functionality to their needs through plugins that can access low-level details directly. CLN’s modularity, efficiency and code robustness come with their accompanying downsides, too. Christian Decker, a researcher at Blockstream focused on scaling solutions for Bitcoin, said during the London Bitcoin Devs meetup last month that, by adhering to the UNIX philosophy of doing one thing very well and not forcing decisions on the user, CLN comes in a “bare bones” fashion and requires some dedication from the user to get it working. Notably, Blockstream’s implementation focuses heavily on the specification process and generates a lot of its code out of the BOLT specifications directly, according to Russel. While this ensures a fully spec-compliant implementation, the team is left with less time to market its work and identifies this as the reason it sees less community engagement and node share than other implementations. “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.” The team usually proposes a new specification to the broader development community before adding it to CLN in an attempt to ensure long-term compatibility among different implementations while requesting more eyes to review, test and comment on its code before it is eventually turned into a new BOLT and becomes ready to be adopted by all implementations. “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. Blockstream’s team also has developed a set of new features that extend BOLTs’ current functionality, which are often draft specifications or spec proposals, including collaborative channel openings, liquidity ads and BOLT 12. CLN gives the user the optionality to try out these upcoming specifications. “We rope off draft parts of the Lightning specification under experimental options,” Russel told Bitcoin Magazine. “But if you’re more adventurous, those experimental options give you an insight into what’s coming to the Lightning Network next!” Collaborative channel opens, previously called “dual funding channels,” enable participants to collaboratively open a new channel by jointly funding the channel