What a Lightning Node Bug Teaches Solo Miners

In mid-September 2026, the team behind Core Lightning, one of the most widely run programs for operating a node on Bitcoin's Lightning Network, put out a Core Lightning vulnerability advisory that stopped a lot of node operators mid-task, as Cryptopolitan reported on September 15. Anyone running the software with certain experimental options enabled was told to turn those options off immediately and wait for a patch. By then, reports were already circulating of operators losing funds through the dual-funding feature, even on the latest release.

For the people affected, the sequence was ordinary right up until it was not. A node that had opened and closed payment channels normally for months, funded with bitcoin the operator controlled directly, suddenly held a balance that did not match what its owner expected. Nobody sent those funds to an exchange. Nobody handed a password to a stranger. The software they ran to stay self-custodial let money move without their consent.

The Core Lightning Vulnerability, in Plain Terms

The flagged options were experimental-dual-fund, experimental-splicing, and experimental-peer-storage. Dual funding and splicing let two parties jointly fund a payment channel or resize it without closing and reopening it. Operators enabled them because they are useful. According to the SlowMist summary carried by PANews, a remote peer could set arbitrary or zero fees during a channel open or a funding adjustment without enough local checks, forcing a node to pay abnormal fees or fall into a crash loop. The project has not published a full postmortem or a confirmed total lost, and this piece will not guess at either.

This is the second Core Lightning security scramble in a matter of weeks. In August, a wave of vulnerability reports led the team to recommend an emergency release, version 26.06.7, on August 28. Its source stayed under a two-week embargo and went public on September 11. The labels on these September features said "experimental" for a reason. The project told operators, in advance, which parts of the code had not yet earned the trust the rest of the software has.

Self-Custody Was Never the Finish Line

Here the Core Lightning story becomes a self-custody story that reaches well past Lightning. Running your own node, holding your own keys, or mining directly to your own address all remove one specific risk: a third party deciding what happens to your money. None of them remove the risk that the software between you and your funds has a bug nobody has found yet. Self-custody changes who you trust. You still have to trust something.

That applies to Bitcoin, Litecoin, Dogecoin, and Bitcoin Cash miners the same way it applies to Lightning node operators. A miner who solo mines to their own address, instead of through a pool that holds balances, has already removed one counterparty. What remains is trust in the mining software, the pool's connection protocol, and the coinbase transaction itself. NexusPool's own core software is not public source code today, and this post will not claim otherwise. Non-custodial design and open verification tools answer the same problem from two directions, and neither one replaces the other.

What Verification Looks Like After the Core Lightning Advisory

The advisory helps because the team did not ask operators to trust that a fix was coming. It named the configuration flags at risk, so you could check your own setup against a concrete list. The August release offered a sharper lesson. Docker images pulled between August 28 at 16:04 UTC and September 1 under four tags, including latest, printed v26.06.7 at startup without containing that version's fixes, as the project later added to its release note. A version string told those operators nothing. The image digest told them everything. Checkable evidence beats a label, even a label the software prints about itself.

The same principle drives NexusPool's Glass Ledger, which gives miners a signed, offline-checkable record of pool work and payouts instead of a dashboard number to take on faith. NexusPool's Payout Preflight tool works the same way for the coinbase transaction: it reconstructs and checks the payout before a block is ever found, so you are not relying on a promise about what happens when one is. None of this changes the math of solo mining. Your odds of finding a block depend only on your hashrate relative to network difficulty, identical at every pool on a given chain, and no pool, protocol, or verification tool moves them. These tools change whether you take the rest of the process on faith or check it yourself.

Back to the Node Operators

Go back to the operators who opened their node dashboards this month and found less than they expected. Nothing about their setup was reckless. They ran well-known, actively maintained software and enabled features the project itself shipped. The lesson is narrower than "never run experimental software." Self-custody is the starting point for a smaller, more specific kind of trust, one you can check instead of assume. The page describing how NexusPool's Stratum V1 and Stratum V2 connections are built lays out that narrower trust for mining. This is not investment advice, and it is not a claim that any software, NexusPool's included, is immune to the kind of bug that hit Core Lightning this month.

Trust nothing. Verify the software sitting between you and your keys, not just who holds them.