Lightning Private Channels: Better Privacy, Worse Routing, and the Hidden Costs

Lightning private channels offer a simple promise: keep your channel out of the public graph, and nobody can route payments through it or link it to your node. Most mobile wallets open private channels by default. The privacy benefit is real, but it comes with routing limitations, discoverability tradeoffs, and privacy leaks that the term "private" tends to obscure.

This article explains the difference between announced and unannounced Lightning channels, why the distinction matters for routing and privacy, and how newer mechanisms like blinded paths change the calculus. Understanding these tradeoffs is essential for anyone running a Lightning node, building a wallet, or evaluating Layer 2 privacy models.

How Channel Announcement Works

The Lightning Network maintains a shared map of all public channels through the gossip protocol defined in BOLT 7. When two nodes open a channel and want it to be routable, they exchange a channel_announcement message containing cryptographic proof that the channel exists on-chain. Every node that receives a valid announcement it has not seen before stores it and forwards it to its peers.

BOLT 7 defines three core gossip message types: channel_announcement (declaring a new channel), channel_update (publishing fee policies and availability), and node_announcement (advertising node metadata like alias and addresses). Together, these messages build the channel graph that every routing node uses to find payment paths.

This graph is not small. As of mid-2026, the public Lightning Network carries roughly 41,000 active channels across about 17,400 nodes, holding approximately 4,900 BTC in total announced capacity. A full gossip sync requires downloading around 53 MB of data according to LDK measurements, and roughly 45% of all channel_update messages are keep-alive refreshes: timestamp-only changes sent to prevent the two-week pruning deadline from removing the channel.

What Makes a Channel Private (Unannounced)

A private channel is simply a channel whose participants never broadcast a channel_announcement. The channel exists on-chain in exactly the same way as a public channel: it uses the same funding transaction format, the same commitment transaction structure, and the same HTLC mechanics. The only difference is visibility in the gossip graph.

Because the channel never enters the public graph, other nodes cannot discover it, cannot route payments through it, and cannot include it in pathfinding calculations. The channel exists only between its two endpoints. Bitcoin Optech prefers the term "unannounced channel" over "private channel" because the privacy guarantee is weaker than the name implies: the channel's funding transaction is still visible on-chain, the channel peer knows all payment details, and as we will see, route hints and probing can reveal the channel to third parties.

Terminology note: Throughout this article, "private channel" and "unannounced channel" are used interchangeably. Neither term appears in the BOLT specifications themselves: BOLT 7 simply defines how announcement works, and channels that skip it have no formal designation.

Why Mobile Wallets Default to Private Channels

Nearly every consumer Lightning wallet opens unannounced channels by default. Phoenix, Zeus, Breez, and most LSP-connected wallets all follow this pattern. The reasons are both operational and privacy-related.

Routing reliability

Mobile nodes go offline frequently. A phone loses connectivity on a subway, gets closed to save battery, or simply gets put in a pocket. If that node's channels were announced, other nodes would attempt to route payments through them and fail. Every failed routing attempt degrades the sender's experience and wastes time in pathfinding retries. Keeping mobile channels unannounced removes unreliable paths from the network graph entirely.

No routing obligation

An announced channel implicitly invites the network to route payments through it. For a mobile wallet with limited battery, bandwidth, and uptime, forwarding third-party payments is impractical. Private channels allow a mobile user to send and receive their own payments without participating in the routing network.

Privacy from graph analysis

Announcing a channel links a node's public key to an on-chain UTXO. Anyone running chain analysis can correlate the node identity with the funding transaction, its inputs, and potentially the user's other on-chain activity. Private channels avoid this linkage in the gossip graph, though the on-chain funding transaction itself remains visible to anyone scanning the blockchain for outputs matching Lightning's expected format.

How Private Channels Receive Payments

The central routing problem for private channels is inbound discoverability. A sender constructs a payment route by traversing the public channel graph. If the recipient only has unannounced channels, no route can reach them through normal pathfinding. Two mechanisms exist to solve this: route hints (BOLT 11) and blinded paths (BOLT 12).

Route hints in BOLT 11 invoices

When a node with only private channels generates a BOLT 11 invoice, it includes route hints in the invoice's r field. Each hint describes a partial path from a publicly reachable node into the recipient. Per hop, the hint carries the intermediate node's public key, the short_channel_id identifying the channel, the base and proportional fee the hop charges, and the CLTV expiry delta.

The sender uses regular pathfinding to reach the first node in the hint, then appends the hinted hops to complete the route. In Core Lightning, the node selects hints from its incoming channels, preferring unannounced channels, requiring that the peer be connected and the channel be in a normal state with sufficient balance. Some randomness is added to the selection to prevent systematic probing.

Blinded paths in BOLT 12 offers

BOLT 12 replaces route hints with blinded paths. Instead of exposing the recipient's node and channel IDs, the receiver constructs an encrypted partial route. The sender can reach the entry point of this blinded path but learns nothing about the nodes or channels beyond it: not the recipient's identity, not the channel IDs, not even how many hops are inside the blinded segment.

The flow works through onion messages. A payer fetches an invoice by sending an onion message to the offer's blinded path. The invoice it receives contains additional blinded paths for the payment itself. The payment is then routed to the blinded path entry point and forwarded through the encrypted segment to the recipient. At no point does the sender learn the recipient's node public key.

The Privacy Paradox of Route Hints

Route hints create a fundamental tension. A private channel exists to stay hidden from the network graph, but every invoice the recipient generates must reveal enough information for the sender to reach them. This information leaks the very details that the channel was meant to protect.

Each route hint exposes the channel peer's public key and the short_channel_id. The short_channel_id encodes the funding transaction's block height, transaction index, and output index. Anyone with the invoice can look up the exact on-chain UTXO that funds the channel, identify the peer node, and potentially link the recipient to other on-chain activity. Since BOLT 11 invoices are shared with every potential sender, this information spreads with every payment request.

Privacy comparison: Route hints leak the channel's funding UTXO to every sender. Blinded paths hide this information entirely. If your threat model includes senders as potential adversaries, BOLT 12 offers with blinded paths provide meaningfully stronger privacy than BOLT 11 invoices with route hints.

Probing Attacks and Channel Discovery

Even without route hints, private channels are not immune to discovery. Research by Tikhomirov et al. in their 2020 paper "Probing Channel Balances in the Lightning Network" demonstrated that an attacker can learn channel balances of public channels by sending payments designed to fail, taking under a minute per channel. While the paper notes that private channels are not directly susceptible to the same probing methodology, it describes a workaround: scanning the blockchain for outputs matching the Lightning funding transaction format and cross-referencing against the public gossip graph to identify channels that were never announced.

A follow-up study by Biryukov, Naumenko, and Tikhomirov (IACR 2021) refined the approach, showing that an attacker can accurately update balance estimates without directly connecting to victim nodes. The fundamental problem is that Lightning's on-chain footprint is distinctive: a 2-of-2 multisig output with a recognizable script structure reveals channels to anyone who knows what to look for, regardless of whether those channels were announced.

Network Fragmentation and the Hidden Graph

The widespread use of private channels creates a significant gap between the visible network and the actual network. Estimates suggest that unannounced channels hold roughly twice the capacity of the public graph. With public capacity near 4,900 BTC as of mid-2026, total Lightning capacity including private channels may exceed 12,000 BTC. These figures are inherently imprecise: private channels are, by definition, not directly measurable.

This hidden capacity has practical consequences for the network. Pathfinding algorithms operate on the public graph, so they cannot take advantage of private channel liquidity for multi-hop routing. A network where more than half of all capacity is invisible to routers is a network where pathfinding is working with an incomplete picture. The result is suboptimal routes, higher failure rates for payments that could have succeeded through private channels, and a routing graph that underrepresents the true topology.

LSP concentration

Because mobile wallets connect to the network exclusively through their Lightning Service Provider, the LSP becomes a routing bottleneck and a privacy chokepoint. The LSP sees every payment the user sends or receives. If the user has a single private channel to a single LSP, that provider has complete visibility into the user's payment activity: amounts, timing, and counterparties. This is a different kind of privacy leak than the gossip graph exposure that private channels are designed to prevent.

Public vs Private Channels: Complete Tradeoff Comparison

The decision between announced and unannounced channels involves balancing privacy, routing capability, and operational overhead. Neither option is universally better: the right choice depends on the node's role in the network.

BOLT 12 Adoption and the Path Forward

Blinded paths represent the most significant improvement to private channel privacy since the concept was introduced. By removing the need for route hints, they eliminate the primary information leak that undermined the privacy of unannounced channels. However, adoption remains uneven across implementations.

As of 2026, Core Lightning and Eclair ship with BOLT 12 offers enabled by default. LDK reached full BOLT 12 support in 2025. LND, the implementation with the largest node share, only began landing BOLT 12 functionality in 2026. Until all major implementations support blinded paths, many private channel users will continue relying on route hints that partially defeat the purpose of keeping their channel unannounced.

The transition also introduces a new tradeoff: longer blinded path segments improve anonymity by hiding more of the route, but they increase fees (each blinded hop charges forwarding fees) and reduce the probability of successful delivery. Wallet developers must balance anonymity set size against payment reliability, a tuning problem that does not arise with simple route hints.

Implementation gap: Until LND ships full BOLT 12 support, the Lightning Network cannot achieve uniform blinded-path coverage. Wallets and services that need to interoperate across implementations still fall back to BOLT 11 invoices with route hints, preserving the privacy leaks that blinded paths were designed to eliminate.

Beyond Private Channels: How Spark Handles Privacy

The entire private-vs-public channel dilemma exists because Lightning relies on a gossip-based routing graph. Channels must either participate in that graph (sacrificing privacy) or opt out of it (sacrificing discoverability). This is an inherent consequence of Lightning's source-routed, channel-based architecture.

Spark sidesteps this tradeoff entirely. Spark transfers never appear in any public gossip protocol or channel graph because Spark does not use channels at all. It uses a statechain-based architecture where ownership of Bitcoin transfers through cryptographic key rotation rather than channel-routed payments. There is no routing graph to announce to or hide from: transfers are direct between participants, mediated by FROST threshold signatures.

This means Spark offers stronger default privacy than even Lightning's private channels. No gossip messages leak channel existence. No route hints expose funding UTXOs. No pathfinding algorithm needs a map of the network. The privacy model is not a configuration choice: it is a structural property of the protocol.

For developers exploring these tradeoffs, the Spark SDK documentation covers how to integrate off-chain Bitcoin and stablecoin transfers without the channel management overhead that Lightning requires. For a hands-on comparison of how Spark, Lightning, and on-chain Bitcoin payments work in practice, see the Lightning Network privacy analysis and the Spark UX advantage breakdown.

Practical Guidance for Node Operators

The right channel strategy depends on what your node is designed to do.

When to use public channels

• You are running a dedicated routing node and want to earn routing fees
• You operate a merchant service that needs to receive payments without requiring senders to use route hints
• You are an LSP providing connectivity to mobile wallets
• Your node has high uptime and you want to contribute to network routing capacity

When to use private channels

• You are a mobile or intermittently connected user
• You want to avoid linking your on-chain UTXOs to a public node identity
• You do not intend to route third-party payments
• You are testing or running personal infrastructure and do not need external discoverability

Hybrid approaches

Some node operators maintain both public and private channels. Public channels face the network for routing, while private channels connect to personal wallets or specific counterparties. This approach provides routing revenue and network contribution through the public channels while keeping personal payment activity off the gossip graph. The operational cost is managing two sets of channels with different liquidity requirements.

Key Takeaways

Lightning private channels solve a real problem for mobile users, but the term "private" deserves scrutiny. Route hints leak funding UTXOs to senders. Probing attacks can discover unannounced channels on-chain. The gossip network loses visibility into more than half of total capacity, fragmenting the routing graph. Blinded paths in BOLT 12 fix the route hint leak but introduce their own tradeoffs around fees and reliability, and adoption across implementations is still incomplete.

For users whose primary concern is privacy, the question is whether Lightning's channel-based model can provide it without sacrificing too much routing functionality. Protocols like Spark that avoid the channel graph entirely offer a different answer to the same question: one where privacy and discoverability are not in conflict because there is no public graph to opt into or out of.

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.