Lightning Network : our high-maintenance crazy-ex

A third look at the state of the Lightning Network from and end-user perspective

Back a few years ago, myself and some others wrote about the early state of the Lightning Network. It’s good to revisit some of these things now and then. It’s 2025 now. LN should be “there” by now, I guess. The Lightning Network in 2024¹ versus April 2018² ³ is already a big difference.

I wrote about the Bitcoin Lightning Network with a mix of hope and skepticism back in the day. A couple of years later, I doubled down on my thoughts, pointing out how its growing pains and unrealized potential still plagued its real-life use.

Now, as we “celebrate” the Lightning Network’s eighth birthday (the first official Lightning transaction happened on May 10th, 2017), it’s time to take a hard look at where we are. Spoiler alert: it’s not where we hoped it would be.

The Lightning Network was supposed to be Bitcoin’s killer app for scalability and usability (there’s that word again). It’s cheap, fast, off-chain, and its transactions preserve semi-anonymity (if there is such a thing on a total-control internet). It also adheres to Bitcoin’s decentralization and security.

And to be fair, it kinda works. It’s not the disaster some make it out to be. The critique from some shitcoiners is unfounded—those who say things like, “Who uses Lightning, man? I don’t see it being used anywhere” (while they’re staring at their unsold Bored Ape tokens in some cheap hotel room).

The growth of the Lightning Network shows very steady progress in the number of LN nodes, channels, and their capacity. On the surface, that seems like a success, no? It is—but growth in numbers only shows so much.

Lightning Network, for now, is “all we have.” The companies that bet on it will, of course, keep promoting it, as the necessary investments (like Point-of-Sale systems) have already been made.

The charts, however, can’t be our guidance. We’re not fiat-chart-staring corporate types, after all. We look at real-life use and find holes to plug. And in Lightning, there’s no shortage of that.

Where does all the trust go?

As we’ve seen before in our 12 Food for Thought series, all money needs to have “trust” as a core incentive. The Lightning Network (LN) is no different. When the apps are not usable, the channels close unexpectedly, or the nodes bug out, then you lose customers—and trust.

Yes, you can send sats across the globe in seconds for peanuts. We achieved that. User-facing apps like CoinOS have done a stellar job making Lightning feel almost as smooth as Cash App or Venmo.

But “kinda works” isn’t good enough when you’re trying to build the future of money—certainly not good enough when you’re trying to build an income or onboard a business into accepting Lightning, only to find out it’s not reliable enough.

The Lightning Network’s Achilles’ heel—its unreliability in service delivery—hasn’t gone away. If anything, it’s become more glaring as the network has grown. As more and more flavors come out, the difficulty and complexity only grow.

I dare to predict that Lightning will keep growing a bit further (maybe two more years, tops), and then be eaten alive by a competitor system that is more reliable, redundant, and easier to use. Because we can’t scale this at all. And everybody I talk to knows it. Yet we keep betting on the horse with three legs to win the race.

I don’t get that.

Let’s unpack why that is… after eight years, it’s still more of a hobbyist’s playground than a robust financial infrastructure.

1 - The high-maintenance:

Babysitting nodes isn’t fun, neither profitable

Running a Lightning node sounds cool in theory. Bitcoiners often say, “Running a node is a must.” You can even “vote” with a node for the future of the network, they say. You’re a part of the network, routing transactions, earning tiny fees, and sticking it to the centralized banking system—in theory.

In practice? It’s a pain in the ass.

Setting up and maintaining a node requires some technical know-how (although there are plug-and-play solutions that seem to work), but above all, it needs near-constant monitoring and a willingness to throw time and money into something that rarely pays off.

Channels need to be balanced, liquidity needs to be managed, watchtowers need to be watched… and if you don’t know what you’re doing, you’re stuck with a node that’s more offline than online—or gets ripped off by clever hacker types. Even if you’re a pro, you’re at the mercy of software bugs, network hiccups, or peers who don’t play along.

There are automated tools to help—services like LNDHub or Lightning Pool—but these bring their own headaches. I’ve yet to meet a single person who’s run a full Lightning node and said, “Wow, this is really my cash cow, and so fun to maintain, you’ve got to join in, man.” It’s more like, “Yeah… and I was on a family trip when all of a sudden I got an alert that my node was offline, and I had to get back to reboot it.”

Most node operators I know are either bleeding money or doing it for ideological reasons—not profit. In my opinion, that can be a cool hobby, of course… but not something most businesses can rely on right now.

The incentives for running such a node on a longer time scale just aren’t there for most individuals or smaller businesses. Unless you’re integrating it into a broader Strategy (pun intended)—to sell other stuff or earn money on lending and such on top of that, like Strike does.

As a hobbyist LN node maintainer, you’re sinking hundreds (if not thousands) of dollars into hardware, electricity, and locked-up Bitcoin for liquidity. All for what? A few sats here and there? Compare that to running a Bitcoin full node, which at least feels like a public service with minimal upkeep. Lightning nodes, on the other hand, feel like a second job at Starbucks—but one that doesn’t pay.

You could even say that the network’s growth is more due to the lack of real good alternatives than the popularity of the solution. If something replaced LN nodes tomorrow—some small, easy-to-run, install-it-on-your-phone kind of mini-node that anyone could use—it would take over Lightning in no time and surpass it.

We don’t have that. So the demand for mini-payments grows in a natural way, while users “choose” the Lightning Network more out of necessity than real free market choice.
If you want to accept Bitcoin in your bar, you’re going for Lightning right now.
Period.
(it’s not that anyone has a liquid bitcoin ready wallet in their pocket right now)

2 - Core issues: redundancy & resilience

The real core issue, in my opinion, runs deeper. It’s not just about node maintenance—it's about the design and architecture of Lightning itself. It’s called a Network for a reason: it finds paths, it routes. Routing means you rely on nodes and connections. The security comes from multi-signature agreements between nodes (to put it simply).

But this breaks trust when there’s no way to make it fully redundant.

This is a virtual arm-wrestling contest between trust through security on one side of the table, and trust through reliable, redundant operation on the other. Right now, security wins over reliability. Many people like that—security is, of course, a top priority. But Lightning’s fundamental lack of redundancy makes that second arm-wrestler a bit of a poser. Like a souped-up bodybuilder who looks tough but never learned to fight. The muscles are there, and the baby oil makes it all shine, but there’s little substance in real life.

In traditional telecom networks, redundancy is paramount. If you’re routing traffic from point A to point E, you’ve got options: go through B, C, or D. If B goes down, the system reroutes through C or D. If E itself fails, there’s usually an E(b)—a backup server, router, or DNS—that picks up the slack. This is how the internet stays up even when hurricanes hit or cables get cut.

In Lightning, we don’t have that luxury. Channels are bilateral agreements between two nodes, doing a 2-of-2 multisig, which settles on-chain. Each channel’s state (balance, HTLCs, etc.) is maintained off-chain and evolves with every transaction. Duplicating this state to a sort of backup node would require replicating the exact channel state, private keys, and revocation secrets—which introduces serious complexity and security risks.

If a critical node or channel goes offline, you’re basically screwed. (At one point, a few years ago, one operator messaged me directly to beg me to split a hefty on-chain transaction in two, just to get out of the predicament of closed channels.) That was the moment I knew: we’re not ready yet.

Same goes for unexpected network or hardware outages. And they do happen—all the time, even to giants like Google or Amazon. The impact of a Lightning node—or even a whole datacenter—going down is significant. There’s no automatic rerouting to a backup. Sure, the network tries to find another path, but Lightning’s channel-based system means options are limited.

If point E is down for hours for whatever reason, your transaction might just fail. And your funds in that node’s co-signed channels? Stuck. And if you’re relying on a hub like ZBD, Strike, or CoinOS (which, by the way, is one of the best in the game for user experience), there’s no hot-swappable backup ready to take over.

A recent outage at CoinOS ⁴ drove this home—not because they dropped the ball, but because Lightning’s architecture makes true redundancy nearly impossible. (It is possible in theory, but in practice, I haven’t seen it done at scale anywhere.) You can’t just spin up a duplicate node and expect it to seamlessly take over the original node’s channel states, liquidity, and routing tables. It doesn’t work that way, because of how security is implemented in practice.

Redundancy schemes—fault tolerance, high availability (99.999%), geographic redundancy, physical redundancy—give networks the reliability required for trust. That’s achieved by duplicating hardware, enabling failover through server clusters, distributing resources across locations (including network locations—not just one AS number), and providing alternate physical infrastructure to minimize downtime during failures.

In Lightning, you’re usually looking at small-time operations that—if they’re even running from a datacenter—have no spare servers and no hot-swappable gear nearby. The proverbial “server in my mom’s basement” is a reality here.

Let’s be clear: Lightning’s security model is good. The cryptography behind payment channels works as advertised. But reliability isn’t just about security—it’s about service delivery. Can you count on your payment going through when you need it to?

Too often, the answer is no.

Failed payments, stuck channels, and offline nodes are par for the course. For small, casual transactions—like buying a coffee or tipping a streamer—this might just be an annoyance. Certainly if you use Lightning only every few months at a meetup or that one café that accepts Bitcoin, you’ll probably think everything runs fine. You’re not confronted with how challenging it really is day-to-day.

But for merchants, service providers, or anyone trying to use Lightning at scale, it’s a dealbreaker.

Imagine a telecom provider telling you, “Yeah, your call might drop every two minutes, but don’t worry—the encryption is top-notch, and it works on my machine!” You’d switch carriers in a heartbeat.

3 - No offers to improve for now

Lightning’s “upgrade” or improvement cycle isn’t like your typical operating system update. While the customer-facing side evolves rapidly—wallets, interfaces, UX—all that’s mostly just polish. Under the hood, the last few years (from 2023 onward) haven’t brought much in the way of real upgrades. The core problems—scaling and redundancy—still haven’t been meaningfully addressed.

One theoretical solution that got some attention was Static Channel Backups (SCB). This feature is supported by most major Lightning Network implementations, like LND and Core Lightning (formerly c-lightning). SCBs let users export a snapshot of their node’s channel metadata to an external file. This file contains basic details like channel points and capacities—but not the full cryptographic state or private keys. That’s by design: you’re not supposed to just copy and clone a full node’s funds and channel logic.

In the case of a node failure—say, a hardware crash—you can theoretically restore the node on new hardware using the SCB file and your node’s seed phrase. But SCBs are designed for recovery, not live failover. Restoring usually means re-establishing connections with counterparties or, in many cases, force-closing outdated channels. That settles funds on-chain, disrupts off-chain payment flows, and creates fees and delays.

SCBs are also only useful if your node isn’t offline for too long. If it is, counterparties will start force-closing your channels preemptively to secure their funds. So it’s not a true backup in the real-time sense—it’s a “salvage operation” at best.

Now, for higher availability, there’s the idea of hot standby nodes—a secondary node that mirrors the primary in real time. In theory, this could work. In practice, it’s a minefield.

Keeping state perfectly in sync is hard. Any desync risks invalid state broadcasts, which can trigger penalty transactions. And trying to run two nodes with the same private keys concurrently? That’s a major security nightmare. Even large hubs like ACINQ or Bitrefill—which do have serious infrastructure—don’t have real-time channel state redundancy. Why? Because it’s just not feasible with how Lightning is currently designed.

So the reality is: true redundancy in Lightning still doesn’t exist. The building blocks (SCBs, watchtowers, multi-region nodes) are pieces of a puzzle that hasn’t been solved yet.

Cat names Cruella sleeping next to a Lightning node

Where Do We Go From Here?

Eight years in, the Lightning Network stands at a crossroads. It has proven that it can work—in theory. But in practice, it remains a patchwork of half-baked solutions held together by duct tape, goodwill, and heroic efforts. To truly move forward, we need to confront and solve its core issues:

1. Incentivize Node Operators: Running a node needs to be worth the effort. That could mean better fee structures, simpler liquidity management, or even gamified rewards for uptime and reliability. If operators aren’t making money or having fun, they’ll keep dropping out—especially when new players show up to claim the micro-payments market (as so many shitcoins are constantly trying to do).

2. Build real redundancy systems for Lightning nodes: The network needs a serious rethink on routing and failover. Whether it’s via multi-path payments, smarter hub designs, or some yet-to-be-invented protocol, Lightning has to figure out how to keep the lights on when nodes go dark. I’d love to see a system where Lightning nodes operate in trusted twin-pairs across the globe—two nodes in completely different locations acting as each other’s backup, sharing all data and keys solely for redundancy. Yes, that’s a big trust ask, but without real-world redundancy, reliability will remain Lightning’s weakest link.
   
   TwinNodes?
   

   I propose a change in how Lightning operates, with baked-in redundancy— where you (voluntarily!) choose to open up a small part of your node’s security to a trusted twin-node. Picture this: Alice (in Argentina) and Jeff (in Brussels) both run a Lightning node. One day, Alice’s server goes down because her cat Cruella peed on it (yeah, it happens).
   No problem — her trusted twin-node, hosted by Jeff in Brusels, takes over full operation from his own “private datacenter” in his mom’s basement.
   

   The system works because Alice’s watchtower nodes are aware of Jeff’s Node ID and his specific backup role. No one else can impersonate Jeff—only he has the cryptographic permission to act as Alice’s twin.
   
   This would require a rethinking of Lightning’s current design, inherently loosening some of its strict security assumptions. But it would be opt-in. Node operators could choose whether or not to enable this twin-mode.
   

   Of course, if Jeff’s node ever goes down, the process works in reverse—Alice steps in. It’s a trade-off: slightly reduced isolation in exchange for actual failover. Those who dislike the idea can simply ignore it and accept that when their node dies, it’s offline with the users and funds left out to dry.
   
   Meanwhile, twin-nodes in geographically and infrastructurally diverse areas keep running with higher uptime and stronger reliability.
   

3. Prioritize UX. Projects like CoinOS and SwissBitcoinPay show what’s possible when user experience is the focus. These apps make Lightning feel like a real product—not a weekend hackathon project. More Lightning implementations need to follow their lead. Simplify onboarding. Abstract away the channel balancing headaches. Make Lightning work like a consumer app, not like a sysadmin puzzle.

   Right now, most Lightning wallets and tools are still too clunky, too technical, or just plain confusing. That might be fine for hobbyists and devs, but it’s a dealbreaker for the average user.
   If you want people to trust Lightning for real payments, it needs to feel like Venmo or Revolut — not like configuring a Suse Linux server in 2005 .
   

4. Acknowledge the Limits. Maybe Lightning isn’t the end-all, be-all solution for Bitcoin scaling. Layer 3 solutions, sidechains, or even (gasp) custodial services might have a role to play in the ecosystem. Purists won’t like it, but the reality is that as Lightning stands right now, many users will face unexpected downtime, confusing UX, or frustrating limitations.

   While we push for adoption, we shouldn’t be repelling potential users with constant hurdles. If the goal is mainstream adoption, we need to be open to a variety of solutions—whether it's hybrid approaches, other layers, or temporary custodial systems. Embrace the broader vision for scaling Bitcoin rather than expecting Lightning to be the only answer.

I still believe in the Lightning Network’s potential, but that belief hasn’t grown much since 2018. The idea of instant, near-free Bitcoin transactions is just too compelling to abandon. However, I’m increasingly seeing Lightning as a first step :
a necessary learning curve.
It’s a valuable experiment and a piece of the puzzle, but not the final answer for Bitcoin scaling.

8 tears, 8 years

After eight years, it’s time to stop treating Lightning like a promising startup and start holding it to the standards of a mature system.

Until we fix the reliability problem, it’ll remain a niche tool for enthusiasts, not a global payment network and it might still grow on pure demand for small payments in bitcoin - that’s cool and all.
There will be competition however. And that competition will taking that demand by storm.

Conclusion:

So my conclusion is, that Lightning right now is more like a crazy-ex partner, someone else will pay for him/her’s high-maintenance lifestyle and needs, while you’re still confronted now and then with the shenanigans and drama when that ex pops up out of nowhere.

Maybe it’s time we move on and route around this problem.
I think the Lightning Network was an excellent experiment, one where we’ve learned a lot about what works and what doesn’t. But there must be very smart people out there who can come up with a more lightweight solution—one with less complexity—that enables Bitcoin payments, even for small amounts, while balancing security and offering trust through mechanisms like rebalancing, redundancy, and reliability.

For now, I think pure on-chain transactions and silent payments are the way forward. But I also see what the e-cash people are doing with their implementations like minibits.cash and maybe there’s a solution there somewhere.

For now, I can’t call Lightning a success through the perspective of a daily user, not after I’ve seen things go down, go bust or broken all the friggin’ time.

AVB

Tip jar: https://allesvoorbitcoin.be/donate/

1. The state of Lightning

2. https://medium.com/@kim0raku/cash-in-hand-but-no-sale-179c730ff9d7

3. https://deadeyes.medium.com/winkeliers-op-lightning-network-deel-1-708697adba1b

4. https://njump.me/nevent1qqsd2wlx3wq94sqgh66u9hfsevym55mse87efunrc8qpr0syr8mfezqpzemhxue69uhhyetvv9ujucm0d9hx7uewd9hj7q3qh2qfjpnxau9k7ja9qkf50043xfpfy8j5v60xsqryef64y44puwnqxpqqqqqqzxxr7dv