Short channel ID

Lightning names a public channel by where its funding output sits in the blockchain, not by an arbitrary label. Three bytes carry the block height, three the transaction index and two the output index, which is 64 bits in total, written for humans as 539268x845x1. That coordinate is what lets you verify a channel your wallet is routing through against the chain, without trusting anyone's dashboard.

How it works

The three components of a short channel ID are concatenated most significant first: the block height of the funding transaction, that transaction's index within the block, and the index of the output that pays the channel. The fixed widths cap the height and the transaction index at 16,777,215 and the output index at 65,535.

Written for a person, the numbers are printed in decimal and joined by a lowercase letter x, so a channel on output 1 of the transaction at index 845 in the block at height 539,268 is 539268x845x1. The spec's reasons: a lowercase x is visibly smaller than a digit in most fonts, so the eye separates the parts, and one double-click selects the whole identifier.

Packed it is a plain 64-bit number, and BOLT 11's test vector shows it off: the route hint 66051x263430x1800 is the byte sequence 01 02 03 04 05 06 07 08 in order, because 66051 is 0x010203, 263430 is 0x040506 and 1800 is 0x0708.

Being a position rather than a hash, a short channel ID stops being true if the block it names changes. That is why a channel is not announced until its funding transaction has at least 6 confirmations, and why a node should ignore an announcement whose output has fewer. Splicing moves the identifier too: a spliced channel is announced again under the short channel ID of the splice transaction, while nodes keep relaying payments that still use the older one.

A channel nobody announced has no public identifier, so the peers hand each other an alias instead; an update carrying one must set its dont_forward flag and must never be passed on, for privacy.

Where you see it

Short channel IDs are the addressing layer of Lightning gossip, and they appear in every message about one specific channel.

Message type 259, announcement_signatures, carries one when two peers agree to publish their channel. Type 256, channel_announcement, carries the one every other node uses to find the funding output on chain. Type 258, channel_update, repeats it on every fee or expiry change, once per direction. Type 261, query_short_channel_ids, asks a peer for the announcements behind a list of them, sent as an ascending array under encoding byte 0; encoding byte 1 once meant zlib compression and is now banned outright. A node may prune any channel whose newest update in either direction is older than two weeks, 1,209,600 seconds.

The one place an ordinary user meets one is a payment request: the r field of a BOLT 11 invoice carries route hints, and each hop is a node public key, a 64-bit short channel ID, two fee figures and an expiry delta. The spec's worked example points at 589390x3312x1.

Short channel ID vs Outpoint

A short channel ID and an outpoint both name one transaction output, and they do it from opposite directions. An outpoint is 36 bytes, a 32-byte transaction id followed by a 4-byte index, naming the output by the transaction that made it; a short channel ID is 8 bytes and names the same output by where it landed.

The trade is size against stability. An outpoint is valid the moment a transaction exists, unconfirmed included, and never changes. A short channel ID does not exist until the transaction is in a block, and a reorganization that re-mines it at a different height or position yields a different identifier for the same channel. Lightning accepts that because the coordinate doubles as the instruction for finding the output, and 8 bytes a channel gossips far more cheaply than 36.