Scaling Lightning on Mobile: How Gossip Bandwidth Reduction Unlocks Lightweight Nodes

The Lightning Network enables fast, low-cost Bitcoin payments, but running a Lightning node on a mobile device has always been constrained by one underappreciated bottleneck: gossip bandwidth. Before a node can route a payment, it needs a map of the network. Building that map means downloading and processing tens of megabytes of gossip protocol messages, a cost that desktop nodes absorb easily but that drains mobile data plans and batteries.

This article explains how Lightning's gossip protocol works, quantifies the bandwidth problem, and compares the approaches different implementations use to make lightweight nodes viable.

How Lightning Gossip Works

Lightning nodes discover network topology through a peer-to-peer gossip protocol defined in BOLT 7. When a node connects to the network, its peers forward three types of messages that together describe the payment channel graph.

Channel Announcements

A channel_announcement (type 256) declares that a payment channel exists between two nodes. It contains four 64-byte signatures (two from node keys, two from the Bitcoin keys backing the channel), the funding transaction reference, and both node public keys. Each message is roughly 430 bytes on the wire. A channel can only have one valid announcement, and it must have at least six on-chain confirmations before peers will relay it.

Channel Updates

A channel_update (type 258) carries the routing parameters for one direction of a channel: the base fee, proportional fee rate, CLTV expiry delta, and HTLC size limits. Each update is roughly 132 bytes. Every channel needs at least two updates (one per direction), and nodes re-broadcast updates whenever their fee policies change. Crucially, channels with no update newer than two weeks are pruned from the graph, so nodes must periodically re-announce even if nothing has changed.

Node Announcements

A node_announcement (type 257) advertises a node's alias, color, network addresses, and supported features. These are only processed for nodes already seen in a channel announcement. Address types include IPv4, IPv6, Tor v3 (37 bytes each), and DNS hostnames.

Keep-alive overhead: Research from the paper "On the Routing Convergence Delay in the Lightning Network" found that 45.32% of all channel updates are keep-alive messages with identical content except for a refreshed timestamp. Nearly half of all gossip traffic exists solely to prevent the two-week pruning timer.

Quantifying the Bandwidth Problem

A full gossip sync downloads every channel announcement, both direction updates, and node announcements for the entire network. According to measurements by the LDK team, a complete peer-to-peer gossip sync consumed approximately 53 MB for a network of roughly 80,000 channel announcements and 160,000 channel updates. That figure represents the raw gossip messages with all cryptographic signatures and redundant fields included.

The problem compounds because gossip uses a flooding model: each message is forwarded to every connected peer. The convergence delay paper measured an average redundancy factor of 2.55x, meaning each gossip message arrives at a node an average of 2.55 times across different peer connections. Roughly 60% of messages are seen three or more times.

Traffic Composition

Not all gossip messages are equal. Empirical measurement of 69,942 unique messages collected from over 1,000 nodes showed the following breakdown:

• 94.53% are channel updates (fee and policy changes, plus keep-alives)
• 5.13% are node announcements
• 0.34% are channel announcements

Channel updates dominate because they change frequently and must be refreshed to avoid pruning. For a mobile wallet that only needs to find a route, most of this data is noise: the wallet cares about graph topology and current fees, not the cryptographic proofs that a desktop routing node validates.

Why This Matters for Mobile

A 53 MB initial sync is manageable over Wi-Fi, but the ongoing gossip stream is the real cost. Blockstream's LNsync measurements showed that 24 hours of incremental gossip catchup consumes approximately 6 MB of uncompressed data. A phone that opens its Lightning wallet once a day must download 6 MB before it can route its first payment. Open it after a week offline, and you are back to tens of megabytes. On metered connections common in emerging markets, this cost is a direct barrier to adoption.

BOLT 7 Gossip Queries: The Built-In Filters

The BOLT specification includes a set of query messages that let nodes request specific subsets of gossip data instead of accepting the full firehose. These were the first step toward reducing gossip bandwidth.

gossip_timestamp_filter

A node sends gossip_timestamp_filter (type 265) to constrain which gossip messages a peer will forward. By setting a first_timestamp and timestamp_range, the node only receives messages within that window. This is the standard mechanism for incremental sync: after an initial graph download, a node reconnects and requests only updates since its last sync time. When the gossip_queries feature is negotiated, a node receives no gossip at all until it sends this filter.

query_channel_range

query_channel_range (type 263) requests all channels opened within a given block height range. The response includes short channel IDs and, optionally, per-channel timestamps and CRC32C checksums. The checksum extension is particularly useful: a node can compare its local channel_update checksum against the remote one and only fetch updates where the checksums differ, skipping channels whose routing parameters have not changed.

query_short_channel_ids

Once a node knows which channels have changed, it sends query_short_channel_ids (type 261) with a per-channel bitmask specifying exactly what to fetch: the channel announcement, channel updates for either direction, or node announcements for either endpoint. This granularity avoids downloading data the node already has.

Limitation of built-in queries: While gossip queries reduce unnecessary downloads, they still require the node to maintain a full channel graph and validate all cryptographic signatures locally. The CPU and memory cost of signature verification is non-trivial on resource-constrained mobile hardware.

Rapid Gossip Sync: LDK's Server-Assisted Approach

Rapid Gossip Sync (RGS), developed by the LDK team, takes a fundamentally different approach. Instead of having the mobile client participate in peer-to-peer gossip at all, a semi-trusted server pre-processes the gossip data and serves it as compact binary snapshots over HTTP.

How RGS Works

The RGS server connects to Lightning Network peers, collects all gossip messages, and validates every signature against the blockchain. It then strips the validated signatures, removes redundant fields (like the genesis block hash duplicated in every message), and encodes channel IDs as incremental deltas. The result is a compact binary blob that the client downloads and applies to its local network graph using RapidGossipSync::update_network_graph().

Bandwidth Savings

The compression is dramatic. For the same network state that requires 53 MB via standard peer-to-peer gossip, the uncompressed RGS snapshot is 4.7 MB. After gzip compression, it drops to approximately 2 MB: a 96% reduction in bandwidth. On a mobile device, processing and applying a full RGS snapshot takes less than 0.4 seconds.

Incremental updates reduce costs further. The client communicates the timestamp of its last known state, and the server returns only data that has changed since then. A client syncing after a few hours of inactivity downloads kilobytes, not megabytes.

Trust Model

RGS introduces a semi-trusted server. The server can lie by omission (exclude channels from the snapshot) or serve stale data, which could degrade routing success. However, it cannot fabricate channels because every channel must have a corresponding on-chain funding transaction. The client still computes routes privately: the server never sees payment destinations, preserving the onion routing privacy model.

How Each Implementation Handles Gossip

The four major Lightning implementations take meaningfully different approaches to gossip management, reflecting their different target environments.

LND

LND uses a SyncManager subsystem with configurable active syncers (default: 3 peers via --numgraphsyncpeers). Active syncers receive and propagate graph updates in real time, while passive syncers only respond to direct queries. On startup, LND performs a historical sync using query_channel_range to acquire the full graph. The outgoing gossip rate limit defaults to 1 MB/s with a 2 MB burst, increased 10x from the original 100 KB/s after performance analysis showed the old limit constrained channel serving to roughly 121 channels per second.

Core Lightning

Core Lightning (CLN) isolates gossip handling in a dedicated gossipd subdaemon within its multi-process architecture. Gossip is stored in a binary gossip_store file with per-record headers including CRC32C checksums. Other daemons and plugins access this store in read-only mode. CLN prunes channels 12 blocks after their funding output is spent on-chain. Blockstream's LNsync plugin provides server-assisted gossip catchup, delivering a minimal set of deduplicated gossip messages for a given time interval.

Eclair and Trampoline Routing

Eclair takes the most radical approach for mobile: it eliminates gossip entirely through trampoline routing. The Phoenix wallet, built on Eclair, stores zero gossip data. Instead of syncing the network graph, it constructs simplified onion routes using only trampoline node addresses. Each trampoline node computes the detailed route to the next hop, offloading the pathfinding work entirely. The tradeoff is reduced privacy: the trampoline node (ACINQ in Phoenix's case) can observe payment destinations.

LDK

LDK, designed as an embeddable Rust library rather than a standalone daemon, offers Rapid Gossip Sync as its primary mobile gossip solution. The RGS crate handles snapshot downloading and graph application, while standard peer-to-peer gossip remains available as a fallback for server-independent operation.

Bandwidth Comparison Across Sync Methods

The following table compares the bandwidth cost and tradeoffs of each gossip approach for a mobile client performing an initial sync and daily incremental updates.

Graph Completeness vs. Routing Success

Every gossip reduction technique involves a tradeoff between the completeness of a node's channel graph and its ability to find successful payment routes. A node with a stale or incomplete graph will attempt routes through channels that have been closed, have insufficient capacity, or have changed their fee policies.

Convergence Delay

The convergence delay paper measured how long it takes for a gossip update to propagate across the network. The average delay was 359.9 seconds (roughly 6 minutes), with a 95th percentile of 753 seconds and a worst case of approximately 2,500 seconds (42 minutes). During this window, some nodes have stale routing information. The researchers estimated a real-world payment failure rate of approximately 1.24% attributable to stale routing data alone.

For mobile clients using server-assisted sync methods like RGS, staleness depends on how frequently the server updates its snapshots and how often the client fetches them. A client that syncs every few hours will have a less accurate graph than a desktop node receiving real-time gossip, but the practical impact on routing success is modest: the pathfinding algorithm retries with alternative routes when the first attempt fails.

The Privacy Dimension

Server-assisted approaches introduce a privacy consideration. An RGS server knows which clients are downloading snapshots (by IP address and timing) but does not learn what payments they make. A trampoline node, by contrast, learns the payment destination. Neither approach leaks the payment amount to the server if onion routing is maintained. Full P2P gossip avoids both concerns but at significant bandwidth cost.

What Comes Next: Gossip v2 and Set Reconciliation

Even with the current optimizations, the gossip protocol's flooding model is fundamentally inefficient. Every message is forwarded to every peer, generating the 2.55x redundancy measured in practice. The Lightning development community is exploring set reconciliation as a replacement, borrowing ideas from Bitcoin's Erlay transaction relay protocol.

The concept: instead of forwarding every message, nodes periodically exchange compact "sketches" of their known gossip sets using Minisketch, a library originally developed for BIP 330. The sketch comparison reveals which messages each node is missing, and only those differences are transmitted. Simulations suggest a 52-56% bandwidth reduction over the current flooding approach. This remains in the proposal and research phase with no production deployment yet.

LND is also developing Gossip 1.75 (PR #8044), introducing new message types for Taproot channels with block-height-based timestamps instead of UNIX timestamps, enabling more efficient range queries.

Spark: Eliminating the Gossip Problem Entirely

While Lightning implementations work to compress, filter, and optimize gossip data, Spark sidesteps the problem entirely. Spark does not use payment channels, so there is no channel graph to discover, no gossip protocol to sync, and no routing table to maintain. Transfers on Spark are direct: the sender and recipient interact with the Spark operators without needing knowledge of network topology.

This architectural difference makes Spark inherently mobile-first. A Spark wallet requires zero bandwidth for network discovery. There is no initial sync, no incremental gossip catchup, and no tradeoff between graph completeness and routing success. The wallet is ready to send and receive the moment it connects, even after being offline for weeks.

Lightning's gossip optimizations have made mobile wallets viable, but they introduce trust assumptions (RGS servers) or privacy tradeoffs (trampoline nodes) that Spark's channel-free architecture avoids. For developers building mobile payment experiences, this is a meaningful simplification.

Implications for Developers

The gossip bandwidth challenge shapes how developers choose Lightning implementations for mobile products. Each approach implies a different set of operational requirements:

• Full P2P gossip demands persistent connections and background processing that conflict with mobile OS power management
• RGS requires running or trusting a gossip sync server, adding infrastructure cost
• Trampoline routing delegates pathfinding to a third party, simplifying the client but concentrating routing intelligence
• Spark's SDK eliminates the decision entirely: no gossip, no graph, no routing infrastructure

Developers building on Lightning should evaluate whether their users will primarily be on mobile with intermittent connectivity. If so, RGS or trampoline routing are likely necessary. For a channel-free alternative, the Spark SDK provides a mobile-native payment layer without gossip overhead. For deeper analysis of how mobile Lightning wallets handle these constraints, see our Lightning mobile wallet architecture guide.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.