Channel Announcement (Lightning Gossip)

What Is a Channel Announcement?

A channel announcement (formally channel_announcement) is a message that a Lightning channel's two endpoints broadcast to the rest of the network. It declares that a funded, confirmed channel exists between two specific nodes and provides cryptographic proof of that claim. The message is defined in BOLT 7, the Lightning specification covering peer-to-peer node and channel discovery.

Without channel announcements, nodes would have no way to learn about channels they are not directly involved in. Every node that receives a valid channel announcement adds the channel to its local topology map, which it then uses to compute payment routes. This is what makes multi-hop routing possible: a sender can find a path to the receiver through channels it has never directly interacted with.

Only public channels are announced. Private channels (those opened without the announcement bit set) are never broadcast and remain known only to the two endpoints. Private channels can still be used for routing through route hints embedded in invoices, but they do not appear in the global network graph.

How It Works

When two nodes open a public Lightning channel, the channel is not immediately announced. Both sides wait until the funding transaction has received at least six block confirmations. Once that threshold is reached, each node sends the other an announcement_signatures message (type 259) containing its node signature and Bitcoin key signature over the announcement data.

After both sides have exchanged signatures, either node can assemble the complete channel_announcement message and broadcast it to its peers. Those peers validate the message and, if it passes all checks, relay it further. The message propagates across the entire network through this gossip process.

Message Structure

The channel_announcement message (type 256) contains the following fields:

type: 256 (channel_announcement)
data:
  [signature]   node_signature_1
  [signature]   node_signature_2
  [signature]   bitcoin_signature_1
  [signature]   bitcoin_signature_2
  [u16]         len
  [len*byte]    features
  [chain_hash]  chain_hash
  [8 bytes]     short_channel_id
  [point]       node_id_1
  [point]       node_id_2
  [point]       bitcoin_key_1
  [point]       bitcoin_key_2

The four signatures appear first in the wire format, but the signed digest covers everything after them: features, chain_hash, short_channel_id, the two node public keys, and the two Bitcoin funding keys. By convention, node_id_1 must be lexicographically less than node_id_2, which ensures a canonical ordering and prevents duplicate announcements with swapped key positions.

The short_channel_id

The short_channel_id is an 8-byte identifier that points directly to the funding transaction output on the Bitcoin blockchain. It encodes three values:

• Block height (3 bytes): which block contains the funding transaction
• Transaction index (3 bytes): the position of the transaction within that block
• Output index (2 bytes): which output of the transaction funds the channel

The human-readable format joins these values with "x". For example, 539268x845x1 means output 1 of transaction 845 in block 539268. This compact encoding lets any node look up the actual funding output on the Bitcoin blockchain to verify the channel exists. For privacy-sensitive use cases, nodes can use a SCID alias instead, which does not reveal the funding transaction.

Why Four Signatures?

The four signatures in a channel announcement each serve a distinct purpose. Together, they establish three facts:

1. The funding transaction pays to bitcoin_key_1 and bitcoin_key_2: verified by looking up the P2WSH output at the short_channel_id location on the blockchain
2. Node 1 controls bitcoin_key_1: proven by bitcoin_signature_1, which is a signature from that Bitcoin key over the announcement data
3. Node 2 controls bitcoin_key_2: proven by bitcoin_signature_2 in the same way

The two node signatures (node_signature_1 and node_signature_2) prove that both nodes agree to make the channel public and are willing to route payments through it. According to the BOLT 7 specification, requiring the Bitcoin signatures proves that the nodes control the channel, while requiring the node signatures indicates that both parties consent to routing other payments via the channel.

This four-signature scheme also acts as an anti-spam mechanism. Because every announcement must reference a real, unspent funding output on the Bitcoin blockchain, an attacker cannot flood the network with fake channel announcements without locking actual bitcoin into funding transactions.

Validation Rules

When a node receives a channel_announcement, it performs several checks before accepting it:

1. Verify that all four signatures are valid against their respective keys
2. Confirm that node_id_1 is lexicographically less than node_id_2
3. Check that the chain_hash matches a known chain (e.g., Bitcoin mainnet)
4. Look up the short_channel_id on the blockchain and verify the output is a P2WSH that pays to the two bitcoin keys
5. Confirm the funding output is unspent and has at least six confirmations
6. Check for unknown even feature bits in the features field; if present, the channel must not be used for routing
7. If a conflicting announcement exists for the same UTXO with different node IDs, blacklist the involved nodes

Only after passing all checks does the node store the announcement and relay it to its own peers. This strict validation ensures the network graph remains accurate and resistant to manipulation.

Role in Pathfinding

Channel announcements are one half of the data that routing nodes need to compute payment paths. The announcement tells a node that a channel exists and identifies its two endpoints. The companion channel_update message (sent separately by each side) provides the dynamic routing parameters: base fee, fee rate, CLTV delta, and minimum/maximum HTLC sizes.

Together, these messages let every node build a weighted graph of the entire network. When a sender wants to pay a receiver, its pathfinding algorithm traverses this graph to find routes with sufficient capacity and acceptable fees. For a deeper look at how this routing works in practice, see the Lightning Network routing deep dive.

Gossip Bandwidth

As the Lightning Network grows, the volume of gossip messages increases. Every new public channel generates a channel announcement, and every fee or policy change triggers channel updates. For mobile and resource-constrained nodes, syncing the full gossip backlog on every connection can be expensive. Rapid Gossip Sync addresses this by letting lightweight clients download a compressed snapshot of the network graph from a server instead of processing individual gossip messages. This is especially relevant for mobile Lightning wallets that cannot stay online continuously.

Use Cases

• Network-wide routing: channel announcements are what make the Lightning Network function as a payment network rather than a collection of isolated point-to-point channels. Without them, senders could only pay direct channel partners.
• Liquidity signaling: liquidity providers and routing nodes announce channels to attract routing traffic and earn routing fees. A well-connected node with many announced channels becomes a hub in the network graph.
• Network analysis: researchers and monitoring services use the stream of channel announcements to track network growth, connectivity, and capacity trends over time.
• Channel verification: wallets and applications can verify that a channel referenced in a Lightning invoice or route hint actually exists by checking for a valid channel announcement.

Risks and Considerations

Privacy Tradeoffs

Announcing a channel reveals the funding transaction on the blockchain and links it to two specific Lightning node public keys. This creates a permanent association between on-chain funds and Lightning identities. For users who prioritize privacy, private channels or blinded paths offer alternatives that avoid public disclosure.

Spam and Resource Exhaustion

Although the requirement for a real on-chain funding output deters casual spam, an attacker with sufficient capital could still create many small channels to bloat the network graph. Nodes mitigate this by ignoring channels below a certain capacity and by applying rate limits to gossip message processing.

Stale Announcements

A channel announcement remains valid until the funding output is spent (i.e., the channel is closed). If a node goes offline and misses the close, its graph may contain stale entries. The gossip protocol does not include an explicit "channel closed" message: nodes detect closures by monitoring the blockchain for spent funding outputs.

Gossip Delays and Convergence

New channel announcements propagate through the network via peer-to-peer gossip, which means there is no guaranteed delivery time. A newly opened channel may take minutes to reach distant parts of the network. During this window, some nodes may attempt to route through a channel they do not yet know about, or fail to include a new channel in their path calculations. Layer-2 solutions like Spark avoid these gossip delays entirely by using a different architecture that does not depend on global channel announcements for payment routing.

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.