Eclair Patched Two Lightning Fee Drains in October. Your Node Still Probably Doesn't Have Them.

Can a Lightning node lose its sats without anyone stealing the keys?

Yeah. That's the whole story here. Eclair just patched two ways your balance can get vaporized into miner fees while your private keys sit safely in your wallet the entire time.

ACINQ pushed both repairs to Eclair's master branch on Oct. 2 and Oct. 5. No key theft. No exotic exploit. Just fee logic that someone else could steer, and you'd foot the bill.

Here's the part that should make operators sweat. As of Oct. 12, Eclair's release page still showed v0.14.3 from September as the latest packaged build. Both October fixes landed after that tag. So if you're running what looks like the current version, you don't have them.

The raw data

Two pull requests. Let's walk them.

PR #3388 targets peer-initiated replace-by-fee during a dual-funded channel open or a splice, which is when a channel's funding gets adjusted. The old logic let a counterparty push for a replacement transaction at a higher fee rate. Eclair would keep its wallet contribution and pay for its own inputs at whatever rate the peer asked for. No ceiling. No budget. No negotiation.

Sit with that for a second. A malicious peer could demand any fee rate it wanted while putting up nothing itself. Your node ate the cost. The sats didn't go to the attacker's address, they went to miners. But gone is gone.

The fix rejects requests above the max funding fee rate Eclair recommends to its peer. Two carve-outs stay. If the peer is buying liquidity and covering Eclair's inputs, fine. If the Eclair node contributes no funds at all, also fine. In both cases, Eclair isn't holding the bag.

PR #3390 is the sneakier one. This lives in Eclair-signer mode, where bitcoind picks coins and builds transactions while Eclair keeps the keys and signs. A compromised backend could report one fee and quietly build a transaction that paid more. The classic move? Drop the change output.

Under Bitcoin's accounting rules, any input value not assigned to an output becomes a miner fee. Missing change doesn't send coins to an attacker's wallet. It just melts them into the block reward. Your keys never left the building and your balance still nuked itself.

The repair does real work. When a fee budget exists, it calculates the actual fee from the amounts of the coins being spent, fetching them by transaction ID to authenticate their values. Then it checks the backend's reported number matches and applies the budget to the real fee. It also verifies Eclair's rebuilt contributions pay that same verified fee and rejects invalid change-output positions.

Why this matters more than the last three Lightning bugs

We've had a run of these. September brought the cooperative-closing fee flaw. Oct. 2 brought restart denial-of-service issues that could crash nodes on every reboot. Now dual-funding, splicing, and signer configs.

That's not random. Lightning's surface keeps expanding. Dual funding, splicing, signer separation, each one is a new place where fee logic can be driven by someone who isn't you.

And here's my hot take. Most node operators aren't running bleeding-edge master builds. They run the latest tagged release. That's the entire point of a release. So a merged fix sitting on master while the release page shows September's build is a fix that helps almost nobody in production.

Anon, let me save you some gas fees: go check your actual build. Not the version number you remember. The commit you're actually running.

The deeper issue is architectural. Signer mode is a legit workflow for people who want key isolation. It's good design. But it hands transaction construction to separate software and trusts that software to be honest about fees. That assumption was doing a lot of unpaid labor until now.

Who wins here? Miners, technically, since they collect whatever gets burned. Who loses? Every operator running a stale build with a patient counterparty on the other side.

What's next

Watch for v0.14.4, or whatever ACINQ tags next. That's the moment the October commits stop being a GitHub curiosity and become something you can actually install. Until then, master is the only place the patches live.

Bitcoin Optech flagged both changes in its Oct. 9 newsletter as closing protection gaps during dual funding and splicing. That's the signal other Lightning implementations pay attention to. If Eclair had this fee-bump hole, is it crazy to ask whether similar logic exists elsewhere in the stack? I don't think so.

If you're running Eclair in signer mode against a backend you don't fully control, treat this as urgent. Same if you're doing dual-funded channels or splices. The attack doesn't need your keys. It needs you on the wrong build and someone on the other end who's willing to wait.

The trenches don't sleep, and neither do the people hunting fee-rate footguns in your node config. Go verify your version before someone verifies it for you.