AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 40 Bitcoin

graph,discovery: version IsZombieChannel

Public commit record

What the developer wrote

Authored by Elle Mouton

63/100 · Adequate
graph,discovery: version IsZombieChannel

Change the IsZombieChannel / isStillZombieChannel function signature
throughout the gossip and routing stacks from
func(time.Time, time.Time) bool to func(ChannelUpdateInfo) bool.

This allows zombie detection to inspect the full channel update info—
including version and freshness type—rather than receiving two raw unix
timestamps that carry no meaning for v2 channels.

Builder.IsZombieChannel is updated to extract version-appropriate
freshness from the ChannelUpdateInfo: unix-time expiry for v1, and a
block-count expiry (derived from ChannelPruneExpiry and
avgBitcoinBlockTime) for v2. The gossipSyncer, SyncManager, and gossiper
Config fields are updated to use the new signature.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit updates how the Lightning Network Daemon (LND) decides whether a payment channel is a 'zombie'—meaning it has gone stale and should be ignored or pruned. Previously, zombie detection only looked at wall-clock timestamps, which works for older v1 gossip channels but not for newer v2 channels that use block heights to show freshness. The change lets the code inspect the full channel update information, including its version and freshness type, so v2 channels are correctly evaluated by block height rather than by time. This is a correctness improvement, not an obvious active vulnerability, but misclassifying v2 channels could affect routing reliability and graph health.

Recommended action

Review the new isTimestampStale logic and the updated call sites to confirm that v2 block-height freshness is correctly propagated everywhere IsZombieChannel is invoked. Run the new TestIsZombieChannel tests and any integration tests covering gossip sync and channel pruning. Monitor for any edge cases where zero/invalid block heights or Unix timestamps are treated as stale, which could cause unintended pruning.

Security signals we found

01

Version-aware zombie pruning closes a correctness gap where v2 channel freshness was evaluated only by time, not block height

02

Removal of a TODO noting that v2 block-height freshness was not handled in gossip sync

03

Refactoring of a security-relevant predicate (zombie detection) across gossip and routing stacks

04

Potential for changed graph pruning behavior on v2 channels, which could affect routing decisions and channel availability

Risk score

Why this scored 40/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.