Private Channel (Unannounced)

What Is a Private Channel?

A private channel is a Lightning Network payment channel that the two participants choose not to advertise to the rest of the network. In standard operation, when two nodes open a Lightning channel, they broadcast a channel_announcement message via the gossip protocol defined in the BOLT specifications. This announcement makes the channel visible to every node, allowing it to be used for routing third-party payments. A private channel skips this announcement entirely.

The Bitcoin Optech project prefers the term "unannounced channel" because "private" implies a stronger guarantee than the mechanism actually provides. The channel still exists on the Bitcoin blockchain as a funding transaction, the channel partner knows everything about it, and various techniques can reveal its existence to outside observers. The privacy benefit is simply that the channel does not appear in the public routing graph.

Private channels are the default for most consumer Lightning wallets and mobile applications. Users who only send and receive payments have no reason to advertise their channels, and doing so would degrade network routing quality since mobile nodes frequently go offline.

How It Works

The distinction between a public and private channel is controlled by a single bit at channel opening time. When one node sends an open_channel message to initiate a new channel (as defined in BOLT #2), the message includes a channel_flags field. Bit 0 of this field is the announce_channel flag:

• If bit 0 is set to 1, the initiator wants to publicly announce the channel
• If bit 0 is set to 0, the channel should remain unannounced (private)

Both peers must agree for the channel to be announced publicly. If either side sets the flag to 0, the channel stays private. The receiving peer may reject the channel entirely if it disagrees with the announcement preference, but it cannot override the initiator's choice to keep the channel private.

The Gossip Protocol

For public channels, after the funding transaction reaches sufficient confirmations, both nodes exchange announcement_signatures messages. These signatures are combined into a channel_announcement (message type 256 in BOLT #7) that is broadcast to the entire network. The announcement contains four signatures, both node IDs, the short_channel_id (encoding the funding transaction's block height, transaction index, and output index), and the Bitcoin keys controlling the funding output.

For private channels, none of this happens. No announcement_signatures are exchanged, no channel_announcement is broadcast, and the channel never appears in any node's routing table. The two peers can still exchange channel_update messages directly between themselves (with the dont_forward flag set in message_flags), but compliant nodes must not relay these updates to other peers.

Reaching Private Channels via Route Hints

Since private channels are invisible to the network graph, senders cannot discover a path to a recipient who only has unannounced channels. The solution is route hints, encoded in the r field (tag 3) of BOLT 11 invoices. Each route hint entry contains one or more hops with the following data per hop:

Route Hint Fields (per hop):
┌──────────────────────────────┬───────────┐
│ Field                        │ Size      │
├──────────────────────────────┼───────────┤
│ pubkey (intro node)          │ 33 bytes  │
│ short_channel_id             │ 8 bytes   │
│ fee_base_msat                │ 4 bytes   │
│ fee_proportional_millionths  │ 4 bytes   │
│ cltv_expiry_delta            │ 2 bytes   │
└──────────────────────────────┴───────────┘

The route hint provides a partial path from a publicly reachable "introduction node" to the recipient through the private channel. The sender's pathfinding algorithm routes to the introduction node using the public graph, then appends the route hint hops to complete the path. The payment is still protected by onion routing: intermediate nodes only see their own hop, not the full path.

Blinded Paths: The Privacy Upgrade

Route hints have a significant privacy drawback: they expose the short_channel_id, which encodes the funding UTXO's on-chain location. Every sender who receives an invoice can identify the funding transaction backing the private channel.

Blinded paths, introduced with BOLT 12 offers (officially merged into the Lightning specification in September 2024), solve this problem. The receiver constructs an encrypted path from an introduction node to themselves where each hop's identity is cryptographically blinded using ECDH-derived shared secrets. The sender only knows the introduction node and cannot learn the recipient's identity, channel structure, or funding UTXOs. For a deeper analysis, see the Lightning Network privacy analysis.

Use Cases

Mobile Wallets

The primary use case for unannounced channels is mobile wallet users. Wallets like Phoenix, Zeus, and Breez open private channels between the user and a Lightning Service Provider (LSP). Mobile nodes go offline frequently: advertising their channels would pollute the routing graph with unreliable paths, degrading routing success rates for the entire network. For more on this architecture, see the research on Lightning mobile wallet design.

Privacy-Focused Users

Users who want to avoid linking their on-chain UTXOs to a publicly known Lightning node identity use unannounced channels. Since the funding transaction is not broadcast via gossip, it is harder (though not impossible) for chain analysis to associate the UTXO with a Lightning node. Combined with onion routing for payment privacy, private channels reduce the metadata footprint of Lightning activity.

End-User Channels

Most end users who only send and receive payments (rather than routing for others) have no reason to advertise their channel capacity. Public channels serve a routing function: they tell the network "you can send payments through me." End users consuming Lightning as a payment rail gain nothing from this exposure. Private channels are the natural default for consumer-grade Lightning usage.

LSP-Managed Channels

Lightning Service Providers frequently open private channels to their customers. The LSP maintains public channels to the broader network for routing, while customer-facing channels remain unannounced. This architecture cleanly separates the routing backbone (public) from last-mile user connections (private). Learn more about this model in the LSP architecture overview.

Why It Matters

Private channels are not a niche feature: they represent a significant portion of all Lightning Network activity. Because unannounced channels are by definition invisible to network observers, precise statistics are impossible. However, multiple analyses suggest that the true capacity of the Lightning Network could be roughly double what is publicly reported, implying that private channels hold a comparable amount of liquidity to the public graph. As mobile wallet adoption grows, the proportion of unannounced channels continues to increase.

For developers building on Lightning, understanding private channels is essential for wallet design, LSP integration, and privacy architecture. Layer 2 protocols like Spark further extend this thinking: Spark uses a statechain-based model that avoids channel management entirely, eliminating the public-vs-private tradeoff while preserving self-custody.

Risks and Considerations

Not Truly Private

The term "private channel" overstates the privacy guarantee. Your direct channel partner always knows your node's public key, your IP or Tor address, the funding UTXO, all payment amounts routed through the channel, and the channel balance at all times. The privacy benefit is limited to exclusion from the public routing graph.

Route Hint Information Leakage

Every BOLT 11 invoice containing route hints exposes the short_channel_id (which encodes the funding UTXO's block, transaction index, and output index) and the public key of the adjacent node. Any sender who receives the invoice can identify the on-chain funding transaction of the private channel. This fundamentally limits the privacy of route hints: recipients must encode their private channel information into every invoice they generate.

Probing and Discovery Attacks

Attackers can discover unannounced channels through several techniques:

• UTXO scanning: analyzing Bitcoin transactions for outputs matching Lightning channel patterns (P2WSH multisig with specific characteristics)
• Balance probing: sending fake payments with fabricated payment hashes through suspected channels and observing error messages to confirm channel existence and approximate balances
• Channel close analysis: when a private channel is closed, the settlement transaction reveals Lightning-specific output patterns (HTLC outputs, timelocked outputs), enabling chain analysis to identify both peers

The practical security assumption should be that any sufficiently motivated observer can discover unannounced channels and the UTXOs backing them. For stronger privacy, users should consider blinded paths with BOLT 12 and trampoline routing. For a comprehensive treatment of these tradeoffs, see the onion routing and Lightning privacy research article.

No Routing Revenue

Private channels cannot earn routing fees from third-party payments because the network does not know they exist. Node operators who want to earn fees from routing must use public channels. This is the core tradeoff: privacy versus participation in the routing economy.

Taproot Channels and the Future

Taproot channels in LND were initially launched as unannounced-only because the gossip protocol (BOLT #7) lacks support for announcing taproot-based funding outputs. A proposed upgrade known as Gossip 1.75 (or Taproot Gossip) would add new gossip messages using BIP-340 signatures and MuSig2 to support public taproot channel announcements. Until that upgrade is finalized, all taproot channels on the Lightning Network remain private by necessity.

Taproot channels benefit privacy even as unannounced channels: P2TR outputs look identical to regular single-signature spends on-chain, making it harder for chain analysts to identify channel opens and closes compared to the P2WSH multisig pattern used by legacy channels.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.