{"id":10147,"date":"2022-04-13T14:04:38","date_gmt":"2022-04-13T14:04:38","guid":{"rendered":"http:\/\/ci029e993610002620"},"modified":"2025-10-01T13:07:35","modified_gmt":"2025-10-01T18:07:35","slug":"blockstream-core-lightning-bitcoin-rebrand","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/blockstream-core-lightning-bitcoin-rebrand","title":{"rendered":"Core Lightning: How Blockstream\u2019s Implementation Rebrand Speaks To Its Long-Term Vision For Bitcoin"},"content":{"rendered":"
<\/div>

Bitcoin infrastructure company Blockstream recently rebranded its Lightning Network implementation from c-lightning to Core Lightning (CLN) in an attempt to highlight the project\u2019s long-term focus on interoperability and specification work.<\/p>\n

The initial name, which alluded to the C programming language the implementation is built in, didn\u2019t reflect the company\u2019s actual intent with the project. Now, Core Lightning seeks to reflect the Blockstream implementation\u2019s value proposition.<\/p>\n

\u201cWe hope the refreshed name better communicates CLN\u2019s focus on interoperability, specification work, and the ongoing aim to provide a reference implementation with priority on correctness and robustness,\u201d the company said in a statement<\/a>.<\/p>\n

Why Are There Different Implementations Of The Lightning Network?<\/h2>\n

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 \u201cmesh network,\u201d from one participant to the next until a final recipient of a Lightning payment is found.<\/p>\n

Therefore, the abstraction that is \u201cthe Lightning Network<\/a>\u201d requires different participants to communicate with each other so they can route each other\u2019s 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. <\/p>\n

Whereas in Bitcoin there is currently a de-facto standard node software, Bitcoin Core<\/a>, 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 \u2014 aka \u201cimplementations\u201d \u2014 can talk to each other.<\/p>\n

The Basis of Lightning Technology (BOLT) documents<\/a> 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.<\/p>\n

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.<\/p>\n

Core Lightning: Built From BOLT<\/h2>\n

CLN<\/a>, 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\u2019s Layer 2 scaling protocol.<\/p>\n

\u201cWe aim to be a high-performance, enterprise-grade, spec-compliant implementation,\u201d Lightning developer at Blockstream, Rusty Russel, told Bitcoin Magazine<\/em>. \u201cThat traditionally means we\u2019re more for high-end users, businesses and developers to build on top of.\u201d<\/p>\n

CLN only works<\/a> on Linux and MacOS, and requires a local or remote bitcoind<\/a> 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<\/a>.<\/p>\n

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.<\/p>\n

CLN\u2019s modularity, efficiency and code robustness come with their accompanying downsides, too. Christian Decker, a researcher at Blockstream focused on scaling solutions for Bitcoin, said<\/a> 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 \u201cbare bones\u201d fashion and requires some dedication from the user to get it working.<\/p>\n

Notably, Blockstream\u2019s 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.<\/p>\n

\u201cWe are built from the Lightning BOLT specifications, literally!\u201d Russel told Bitcoin Magazine<\/em>. \u201cThis 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.\u201d<\/p>\n

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.<\/p>\n

\u201cPart of the reason we do the spec-and-review-across-implementations process is that it helps identify better ways of doing things \u2014 find bugs, identify future problems,\u201d Lisa Neigut, Lightning protocol engineer at Blockstream, told Bitcoin Magazine<\/em>.<\/p>\n

Given its efficiency and lightweight footprint, CLN is likely the best-suited implementation for low-specification devices. <\/p>\n

Blockstream\u2019s team also has developed a set of new features that extend BOLTs\u2019 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.<\/p>\n

\u201cWe rope off draft parts of the Lightning specification under experimental options,\u201d Russel told Bitcoin Magazine<\/em>. \u201cBut if you\u2019re more adventurous, those experimental options give you an<\/p>\n

insight into what\u2019s coming to the Lightning Network next!\u201d<\/p>\n

Collaborative channel opens, previously called \u201cdual funding channels,\u201d enable participants to collaboratively open a new channel by jointly funding the channel funding transaction<\/a>. Currently, channels are open with a unilateral funding transaction by one participant. Collaborative channel opens also enable distributed CoinJoins into a Lightning channel open.<\/p>\n

\u201cYou can orchestrate your own CoinJoin with a bunch of other Lightning nodes,\u201d Neigut told Bitcoin Magazine<\/em>. \u201cYou do it decentralized so the only people that know about who\u2019s involved in that are the people that are actually part of that transaction, so there\u2019s no central coordinator that makes it happen.\u201d<\/p>\n

Liquidity ads also leverage collaborative channel opens. According to a Blockstream blog post<\/a>, \u201cthey are a lightweight way of providing the ability to coordinate liquidity deployment across the network in a decentralized and accessible fashion.\u201d <\/p>\n

The feature attempts to solve a common problem in Lightning: inbound liquidity.<\/p>\n

Liquidity ads allow you to \u201csee 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,\u201d Neigut said.<\/p>\n

BOLT 12<\/a> is another draft specification for Lightning wallets and nodes with experimental support in CLN. The proposed feature, coined \u201coffers,\u201d 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.<\/p>\n

CLN users can now also automate their node management tasks with CLBOSS<\/a>, a recently-released \u201cartificial intelligence\u201d 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.<\/p>\n

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 \u2014 or a similar \u2014 feature is generally good practice, as such a move supposedly caters to the long term interests of Lightning\u2019s broad and ever-growing user base. That being said, the spec process is not an easy task to endure.<\/p>\n

\u201cAs a process it\u2019s arduous and takes a lot of time. It does require coordination with other people with lots of different perspectives,\u201d Neigut said.<\/p>\n

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 \u201ceffort on the specification and low-level implementation details and almost no effort on developer outreach or marketing,\u201d Lightning Labs, the company behind LND, has often chosen to focus more engineering resources on new features and solving customers\u2019 pain points than on the arduous spec process.<\/p>\n

LND: Gaps CLN Can Fill?<\/h2>\n

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.<\/p>\n

\u201cWe 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,\u201d LND Developer Oliver Gugger said<\/a> at the London Bitcoin Devs meetup. \u201cBringing it to the plebs.\u201d<\/p>\n

As a result, LND focuses on \u201chaving a great developer interface,\u201d Gugger added, by enabling gRPC and REST.<\/p>\n

\u201cLND has a great community, easy setup and great developer documentation,\u201d Russel said when asked why he thought LND is the most popular Lightning implementation.<\/p>\n

LND has seen the largest community involvement among all implementations and currently runs the majority of all network nodes. Some estimates<\/a> put LND\u2019s share of total public Lightning nodes anywhere between 70% and 90%.<\/p>\n

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<\/a> and the liquidity services Lightning Loop<\/a> and Pool<\/a>.<\/p>\n

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.<\/p>\n

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.<\/p>\n

With LND\u2019s 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.<\/p>\n

To Spec Or Not To Spec<\/h2>\n

\u201cThe Labs team has come up with great stuff,\u201d Neigut said. \u201cThey just, as an organization, haven\u2019t been amazing about writing specs for the things that they add. A good example of that is KeySend.\u201d<\/p>\n

KeySend allows a Lightning node to send someone a Lightning payment having only the receiving node\u2019s ID, meaning the tool doesn\u2019t require invoices, which are the current de-facto standard<\/a> on Lightning\u2019s payment mechanism.<\/p>\n

\u201cThey launched it, a lot of people started using it, but they never fully specified it,\u201d Neigut added. \u201cSo 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.\u201d<\/p>\n

A spec eventually got written by Spiral\u2019s Lightning implementation, LDK, Neigut recalled, after its team reverse-engineered Lightning Labs\u2019 code.<\/p>\n

\u201cAnd the other teams only really had to follow along because LND has such a large install base,\u201d she said. \u201cThat\u2019s not like the most collaborative process.\u201d<\/p>\n

\u201cThe team of people working on Lightning Labs\u2019 stuff is pretty solid,\u201d Neigut added. \u201cI just think they\u2019re kind of taking advantage of their network dominance to not have to do all this extra work because if they don\u2019t do it, someone else will because the majority of the nodes on the network run their code.\u201d<\/p>\n

Neigut said she is already used to LND being in the spotlight and being the \u201cdefault Lightning\u201d implementation \u2014 something she confesses that she enjoys as a dev because of the fewer customer support demands she receives.<\/p>\n

\u201cBut I think that we\u2019d get a healthier network dynamic if there was no majority implementation,\u201d she added. \u201cI 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.\u201d<\/p>\n

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. <\/p>\n

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 \u2014 which would not necessarily need to be ported back to the spec suite.<\/p>\n

\u201cIt\u2019s hard<\/em> creating an open-source infrastructure company, so it\u2019s not surprising that I don\u2019t agree with all [Lightning Labs\u2019] priorities,\u201d Russel said. \u201cI 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\u2019t think anyone wants to see the network split into pieces.\u201d<\/p>\n

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.<\/p>\n

\u201cIf [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\u2019t be as difficult to follow what they\u2019re doing,\u201d Neigut said. \u201cMaybe they\u2019ll be more involved in the spec process going forward. I think they\u2019ve definitely been getting feedback from us and the rest of the community that the spec process is important.\u201d<\/p>\n

Part of the controversy and tensions in the BOLT spec process<\/a> stem from an email<\/a> 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. <\/p>\n

Bosworth wrote that the BOLT process is an arbitrary standardization process that doesn\u2019t require people\u2019s consent and therefore represents \u201cmore of an opinionated set of documents controlled by an arbitrary process than it is a treaty between independent implementations.\u201d <\/p>\n

Lightning Labs later clarified<\/a> that Bosworth\u2019s comments reflect only his opinion and not necessarily those of the company.<\/p>\n

<\/figure>\n

Decker shared his thoughts on Bosworth\u2019s comments and on the BOLT spec process during the London Bitcoin Devs meetup.<\/p>\n

\u201cI think those are very strong statements from someone who has never participated in a single spec meeting,\u201d he said. \u201cThere 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\u2019t be able to serve all of the different use cases that we are serving.\u201d<\/p>\n

\u201cAnd so yes, sometimes the spec process is frustrating, I totally agree with that,\u201d he added. \u201cWe 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.\u201d<\/p>\n

\u201cI personally don\u2019t work on the spec so I don\u2019t feel qualified to give an answer,\u201d Gugger said at the meetup, commenting on Bosworth\u2019s email. \u201cI just wanted to add that I don\u2019t 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\u2019ll do my best.\u201d<\/p>\n

Russel also commented on Bosworth\u2019s email in a Twitter thread<\/a> where he pledged to spend more time on polishing and marketing CLN, as he said that LND didn\u2019t implement Lightning first and didn\u2019t implement it best \u2014 though its community is great, he added.<\/p>\n

\n

So @alexbosworth<\/a> doesn't understand the Lightning Spec process. I thought Lightning Labs had been so quiet in the last two years because (1) @roasbeef<\/a> is the only one there who's allowed to do spec stuff (2) profitability lead them to pivot to proprietary centralized offerings.<\/p>\n

— TheRustyTwit (@rusty_twit) February 24, 2022<\/a><\/p><\/blockquote>\n