What happened
On 13 August 2026, LND, the most widely deployed Lightning implementation - published
v0.21.2-beta and v0.20.3-beta. Both carry
the same fix to the gossip layer. In the
release notes:
"A peer replying to our query_channel_range could previously make us buffer an unpredictable
number of short channel IDs, as the only limit was a coarse 67MB cap on the bytes a single
zlib-compressed reply could decompress to."
What it changes
When a Lightning node starts up or reconnects, it asks the peers it is connected to which channels they know about in a range of blocks. The answers come back as lists of short channel identifiers, optionally compressed, and one question can be answered across many messages.
The old limit was measured in the wrong unit. It bounded the bytes one compressed reply could expand to, not how many identifiers a whole query could accumulate, and, per the pull request, a compressed reply carries far more identifiers than a plain one, so the two working sets never matched. A peer could therefore answer a single question with as much data as it liked, spread across enough messages. Worse, a reply that failed validation left what had already accumulated in place, so an attacker could pin memory by deliberately causing an error.
The releases cap the decoded identifiers at 100,000 per message set and 100,000 across a single range query, count each reply against its actual encoding, and drop the accumulated state the moment any reply fails validation. The peer doing this needs no channel with the node it is talking to. Gossip is the part of a Lightning node that talks to strangers, so its limits are a security property, not a tuning parameter.
What it does not change
No key, signature or channel balance is involved here, and the release notes claim no loss. This is a resource bound, and whether an unpatched node actually fell over depends on how much memory it had.
But a node that is not running is not watching, and on Lightning that matters in a way it does not on chain. If a counterparty publishes an old channel state, the honest side has to notice and spend the revocation output within the delay the two of them agreed - that is BOLT 5, the protocol's cheating rule, not a vendor's policy. A watchtower exists precisely because the node itself may be down. This is the part of running Lightning that a seed phrase does not cover: self-custody of an on-chain wallet is a backup problem, while a channel is a liveness problem as well.
Context
The same two releases fix two database problems with the same shape: a payment migration that failed on historical routes carrying a blinded total without the encrypted data that should accompany it, and channel databases initialised without a persisted version key, which could skip mandatory migrations and then fail at startup. Keys are the part of a Lightning node that a backup restores. State is the part that has to survive every upgrade after it.