LNbits Killed Hosted Bitcoin Services. The Real Story Is a Two-Month Release Gap.

I was poking around the LNbits repository for an unrelated reason and something stopped me cold.

Not the outage. The commit dates.

Here's the sequence. A security-related change went into the development branch on November 9. On the same day, the project's GitHub page still listed a September backup hotfix as the latest stable release. So anyone who installed the published software, the version the badge tells you to grab, was running code from two months earlier. Two months of whatever landed in between.

That's the story. Not the hosted service going dark. The gap.

I've seen this movie before. It never ends with a dramatic exploit. It ends with a slow bleed of users who quietly stop trusting the deploy.

What Actually Merged

For anyone who hasn't touched LNbits: it's an open-source account system that sits on top of a Lightning node. You point it at a funding source, LND or Core Lightning or a custodial backend, and it gives you wallet accounts, an API, and a web UI. Small merchants use it. Tinkerers use it. People building little community projects use it because it's free and it's in Python and the docs don't make your eyes bleed.

The hosted instance was the front door. Free, no setup, just sign up and go.

That front door is now shut for Bitcoin services with no published restart timeline. Which is a decision, not an accident. When you disable hosted Bitcoin functionality without saying when it comes back, you're telling users something. You just aren't using words.

Now look at the release mechanics, because that's where this gets interesting.

Open-source projects run on a branch model. Development moves fast and messy. Stable releases are tagged, versioned, and sold as the thing you should actually run. The whole contract rests on stable being close enough to development that security patches show up in days, not months.

A September hotfix tagged as the latest stable release in November breaks that contract. Especially a hotfix with "backup" in the name. Read that word again. Nobody ships a backup patch on a Tuesday because everything's fine. Somebody lost data, or came within one bad night of losing it, and the patch got written in a hurry.

And then, on November 9, a security-related change goes into development. Not into a tagged release. Not into a patch version. Into the branch that only people running from source will ever see.

What if the opposite is true? What if the hosted shutdown isn't the security event, and it's actually a symptom of one?

I can't prove that. Neither can you. The public record shows a date and a branch and a stale release tag. But the shape of it's familiar. Small team. Free hosting. Zero revenue attached to the hosted users. Then a patch that takes two months to reach a version number.

Who's Actually Exposed

Let's talk about who's holding the bag.

If you self-host LNbits on your own node, behind your own firewall, with your own funding source, you're mostly fine. You're also running the version you pinned, which might be the September build. So run the update. Check the commits. It takes ten minutes and it's the cheapest insurance on the internet.

If you were on the hosted instance, you've just learned what "free" was buying you. Nothing was in your custody, which sounds like safety until you realize that means you controlled nothing. No keys, no node, no service level, no restart date. Just an API endpoint and a hope.

That's not a knock on the maintainers. It's arithmetic. A free hosted service has no budget for incident response, no on-call rotation, and no legal obligation to bring anything back online. You can't 24/7 a volunteer team with goodwill.

The consensus trade in Lightning right now is "it's fine, it works, ship it." It's crowded. Positions are stacked on the assumption that open-source Lightning infrastructure just keeps running because it always has. Sentiment extremes don't show up in funding rates this time. They show up in how many merchants point a live storefront at a free instance maintained by people who already have day jobs.

The winners here are boring and obvious. Node-in-a-box vendors. Anyone selling self-hosted Lightning to small merchants. Hosting providers running managed LNbits with actual SLAs and a phone number. Every incident like this one is a customer acquisition event for them.

The losers are the two-person shops that built checkout flows on the free endpoint and now have to migrate mid-quarter. And the project itself, which gets a reputational bill it never budgeted for.

My Take: Fade the Panic, Watch the Tag

When the crowd panics, I sharpen my pencil. The panic here's wrong. LNbits isn't dead. The code is open, it's auditable, and the fix exists. That's more than most projects can say.

But there's a version of this where everybody shrugs, the hosted service stays off, the stable tag stays stale, and the project becomes a cautionary line in someone's blog post about maintaining free infrastructure. That's the outcome I'd actually bet on if nothing changes in the next thirty days.

So here's what I'd do with this information.

Check the release tag on anything you run that touches money. If the newest stable release is more than six weeks old and the repo is still committing security work to development, treat your install as unpatched and act accordingly. That's not paranoia. That's reading labels.

Stop treating free hosted custody-adjacent infrastructure as durable. It isn't. It's a demo that got too popular, and demos don't come with an uptime guarantee.

And watch November 9. Not the outage announcement, not the restart timeline that doesn't exist. The commit. If a tagged release lands in the next couple of weeks that folds in that security change, this is a project with a maintenance problem. If nothing lands by mid-December, this is a project with an abandonment problem, and the hosted shutdown was the tell.

Two months between what the maintainers know and what you're running. That's not a gap. That's a window. Somebody should shut it.