Now called Core Lightning, Blockstream’s Lightning Network implementation seeks to be Bitcoin’s interoperable, specification-focused standard.
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 funding transaction. Currently, channels are open with a unilateral funding transaction by one participant. Collaborative channel opens also enable distributed CoinJoins into a Lightning channel open.
“You can orchestrate your own CoinJoin with a bunch of other Lightning nodes,” Neigut told Bitcoin Magazine. “You do it decentralized so the only people that know about who’s involved in that are the people that are actually part of that transaction, so there’s no central coordinator that makes it happen.”
Liquidity ads also leverage collaborative channel opens. According to a Blockstream blog post, “they are a lightweight way of providing the ability to coordinate liquidity deployment across the network in a decentralized and accessible fashion.”
The feature attempts to solve a common problem in Lightning: inbound liquidity.
Liquidity ads allow you to “see all the people that are advertising that they will sell you inbound liquidity if you open a channel to them, which is really exciting stuff,” Neigut said.
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.
CLN users can now also automate their node management tasks with CLBOSS, a recently-released “artificial intelligence” tool that can decide what nodes to open channels to, open channels when fees are low and there are on-chain funds, adjust routing fees to be competitive with other nodes, perform submarine swaps via the boltz.exchange API and automatically rebalance channels.
While different implementations should be encouraged to pursue standalone solutions to their specific use cases while abiding by the current BOLT 11 specifications, putting an accompanying spec proposal forward to help other implementations deploy the same — or a similar — feature is generally good practice, as such a move supposedly caters to the long term interests of Lightning’s broad and ever-growing user base. That being said, the spec process is not an easy task to endure.
“As a process it’s arduous and takes a lot of time. It does require coordination with other people with lots of different perspectives,” Neigut said.
As a result, different companies dedicate different amounts of time and effort to this process according to their individual priorities, which naturally differ. While, according to Russel, the CLN team has spent most of its “effort on the specification and low-level implementation details and almost no effort on developer outreach or marketing,” Lightning Labs, the company behind LND, has often chosen to focus more engineering resources on new features and solving customers’ pain points than on the arduous spec process.
LND: Gaps CLN Can Fill?
LND is a developer-first Lightning implementation that focuses on facilitating the development of applications on top of it, thereby placing strong emphasis on developer interaction, particularly in a standard approach to communication through REST APIs, which enable easier app development, in addition to providing clear documentation and an easy setup experience.
“We want developers to be able to pick it up easily, integrate it into their product, build apps on top of it and distribute it as a wallet or a self-hosted node,” LND Developer Oliver Gugger said at the London Bitcoin Devs meetup. “Bringing it to the plebs.”
As a result, LND focuses on “having a great developer interface,” Gugger added, by enabling gRPC and REST.
“LND has a great community, easy setup and great developer documentation,” Russel said when asked why he thought LND is the most popular Lightning implementation.
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.
Loop uses submarine swaps to bridge on-chain and off-chain bitcoin, making it easy to move bitcoin into and out of the Lightning Network. It performs automated channel balancing, privacy-forward non-custodial swaps, fee-saving opportunistic transaction batching and progress monitoring of in-flight swaps.
Pool is a peer-to-peer marketplace for Lightning channels. It connects users who need access to inbound liquidity to those who have capital to deploy on the Lightning Network by enabling a Lightning Network participant to signal a need for it and incentivizing others to open channels with them using their capital.
With LND’s focus typically on new features and customer support, the CLN team has found a gap in the marketplace it hopes to fill by paying closer attention to the specification process.
To Spec Or Not To Spec
“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.”
KeySend allows a Lightning node to send someone a Lightning payment having only the receiving node’s ID, meaning the tool doesn’t require invoices, which are the current de-facto standard on Lightning’s payment mechanism.
“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.
“And the other teams only really had to follow along because LND has such a large install base,” she said. “That’s not like the most collaborative process.”
“The team of people working on Lightning Labs’ stuff is pretty solid,” Neigut added. “I just think they’re kind of taking advantage of their network dominance to not have to do all this extra work because if they don’t do it, someone else will because the majority of the nodes on the network run their code.”
Neigut said she is already used to LND being in the spotlight and being the “default Lightning” implementation — something she confesses that she enjoys as a dev because of the fewer customer support demands she receives.
“But I think that we’d get a healthier network dynamic if there was no majority implementation,” she added. “I think that would really kind of change the game in terms of the amount of collaboration everyone has to do to get their stuff shipped on Lightning. And that would be healthy.”
Careful attention to specifications is arguably central to open-source development in an open network environment. On Lightning, such specs form the foundation of the protocol and ensure the interoperability of the different versions participating in the network.
However, while some argue major changes and new additions to one Lightning implementation should have an accompanying specification, others might see the BOLT specs as a bare minimum on top of which each implementation can build their own exciting new features — which would not necessarily need to be ported back to the spec suite.
“It’s hard creating an open-source infrastructure company, so it’s not surprising that I don’t agree with all [Lightning Labs’] priorities,” 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.”
Disregarding the spec process completely could lead to the emergence of widely different sub-ecosystems, which could hurt the development and adoption of the Lightning Network as a whole if they were to become non-interoperable. But as Russel highlighted, there is no indication that any implementation is doing that today. Maintaining a cohesive, interoperable interaction between nodes is key if we want to keep implementation details abstracted away from the user and thereby enable a good user experience.
“If [Lightning Labs] were the lead and they were also leading the way in specs, I think that there would be a little less friction around adding new features, because it wouldn’t be as difficult to follow what they’re doing,” Neigut said. “Maybe they’ll be more involved in the spec process going forward. I think they’ve definitely been getting feedback from us and the rest of the community that the spec process is important.”
Part of the controversy and tensions in the BOLT spec process stem from an email shared on Twitter in late February, in which the head of Lightning liquidity at Lightning Labs, Alex Bosworth, commented on BOLT 12 and the BOLT spec process.
Bosworth wrote that the BOLT process is an arbitrary standardization process that doesn’t require people’s consent and therefore represents “more of an opinionated set of documents controlled by an arbitrary process than it is a treaty between independent implementations.”
Lightning Labs later clarified that Bosworth’s comments reflect only his opinion and not necessarily those of the company.
Decker shared his thoughts on Bosworth’s comments and on the BOLT spec process during the London Bitcoin Devs meetup.
“I think those are very strong statements from someone who has never participated in a single spec meeting,” he said. “There is a bit of contention in the spec process but that is by design. If one implementation were able to dictate what the entire network looks like, we would end up with a very myopic view of what the network could be and we wouldn’t be able to serve all of the different use cases that we are serving.”
“And so yes, sometimes the spec process is frustrating, I totally agree with that,” he added. “We certainly have different views on what the network should look like. But by this thesis, antithesis and synthesis process we come up with a system that is much more able to serve our users than if one implementation were to do it alone.”
“I personally don’t work on the spec so I don’t feel qualified to give an answer,” Gugger said at the meetup, commenting on Bosworth’s email. “I just wanted to add that I don’t necessarily agree with all the points that Alex mentioned. I definitely would have said it in a different way as well. I think lack of resources to work on the spec sometimes is interpreted as us blocking stuff which is not the intention and not our goal of course. We want to put in more work on the spec so I hope we will improve there. It is an interesting thing to observe, how that frustration sometimes comes to the surface. Thank you [Decker and ACINQ Developer Bastien Teinturier] for all the work you do on the spec. I need to pick up as well so I’ll do my best.”
Russel also commented on Bosworth’s email in a Twitter thread where he pledged to spend more time on polishing and marketing CLN, as he said that LND didn’t implement Lightning first and didn’t implement it best — though its community is great, he added.
“Turns out they’ve decided they can leverage network dominance into protocol control, and the spec process isn’t ‘real,’” he wrote in the thread. “Lightning Labs has claimed ownership of the Lightning network in many ways: I’ve been reluctant to call them out in public. But the lightning network and community deserves better.”
Russel did not respond to questions from Bitcoin Magazine referring to this thread. Lightning Labs declined to comment.
“Back in 2016 we came from three different directions and decided to join all of the things that we learned during this initial experimentation phase into a single specification so that we could collaborate and interoperate,” Decker said at the meetup. “This experimental phase must always be followed up by a proposal that is introspectable by everybody else and can be implemented by everybody else. Sometimes that formal proposal is missing and that prevents the other implementations giving their own review on that feature. This review is very important to make sure it works for everybody and that it is the best we can make it.”
“Like the name Lightning Network suggests, it very much profits from the network effects we get by being compatible, by being able to interoperate and enabling all implementations to play on a level playing field,” he later added.
Implementations Complement Each Other, They Don’t Compete
Besides that very specific controversy regarding the specification process, Lightning implementations mostly work separately and then together to bring the best and most demanded features to the network, ensuring an overall better user experience.
As a result, 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.
