I’m old enough to remember when the Lightning Network was supposed to solve Bitcoin’s transaction limitations. Instead of being slow and traceable, Lightning payments would be quick and private. Nocoiners would finally be forced to eat their FUD. It’s been five years since its initial launch, but expectations have yet to be fulfilled, and concerned Bitcoiners are worried that the network is being held back by a single dominant implementation.
Lightning is a protocol, a network, and a company. The protocol is defined in eleven Basis of Lightning Technology (BOLT) specifications that were formulated through rough consensus on discussion lists and other public forums. The main Lightning implementations (C-Lightning from Blockstream, Éclair from ACINQ, LND from Lighting Labs, and LDK from Square Crypto) all adhere to these specs.
The Lightning network differs from the Bitcoin network in that software implementations do not need to be entirely compatible. Nodes do not validate blocks, and transactions are peer-to-peer messages as opposed to being stored in a global blockchain. This means a subset of software clients can support extensions of the protocol without worrying about hard forks or lost funds.
Lightning Labs has faced some criticism for its approach. According to C-Lightning developer Rusty Russell, the LND client is a “loss leader” that pushes users towards centralized services for profit. For example, Lightning Loop is a fee-based service that bridges between on-chain funds and Lightning network funds for additional liquidity. Lightning Labs also offers Lightning Pool, a marketplace for Lightning payment channels. C-Lightning has implemented dual-funded channels and Liquidity ads, a decentralized liquidity market, as alternative solutions.
Another complaint involves BOLT12, an additional set of Lightning specifications proposed by Rusty Russell. In its current form, the Lightning protocol requires that users request a unique invoice before each payment. The invoice includes a secret to be revealed in order to claim the payment, making it non-reusable.
This can be an unwieldy process for small and recurring transactions, like subscription charges and tipping. BOLT12 introduces “offers” to make it easier to receive payments. Additionally, the proposal introduces onion messaging and blinded paths to improve privacy for the transaction recipient.
BOLT12 is already implemented in C-Lightning, and the developers at ACINQ and Square Crypto are working on implementations as well. However, Lightning Labs developers have stated that BOLT12 is not a priority, and criticized the proposal for its sizable scope.
In any decentralized system, the dominant implementation tends to become the reference implementation. Google influenced web design with the search engine’s mobile-first indexing, and Apple forced advertisers to change their privacy practices when iOS began blocking ad trackers. The Lightning network happens to be dominated by LND, running over 70% of the network by some estimates. Most Lightning-enabled mobile wallets use LND, and Lightning communities like PLEBNET direct new users to LND as well.
This is partly due to having a user-friendly implementation early on, but also partly because new users confuse Lightning Labs for the Lightning network itself. Either way, Lightning Labs has immense influence over the network protocol, and may simply decline to implement BOLT12 even if it is approved as a protocol specification.
Bitcoin core development is deliberately cautious. This is an $800 billion asset controlled by nothing but software, so it’s sensible to move slowly. When it comes to the Lightning network, there is far less value at stake. It’s not an invitation to be reckless, but the fact that this network is separated from the underlying protocol means it doesn’t require quite as much caution as Bitcoin core development. Features can roll out faster, and software clients can quickly respond to user needs. The hard part is convincing other implementations to adopt features that might threaten their business model.