Glossary / Lightning & layer 2
Node alias
- What is a node alias?
- A node alias is the 32 byte name a Lightning node writes into its own signed node_announcement, giving explorers and wallets something readable to display instead of a raw public key.
Every Lightning node picks its own name and signs it, which is the whole mechanism and also the whole problem. BOLT 7 gives the field exactly 32 bytes, pads the remainder with zeros, and tells receiving software to hint that the name is self signed. Nothing stops two nodes from calling themselves the same thing, so never treat an alias as proof of who you are paying.
How it works
A node alias rides inside node_announcement, gossip message type 257, signed by the same key it names.
The message carries a signature, a feature bitfield, a timestamp, the node_id, a 3 byte rgb_color, the 32 byte alias, and the network addresses the node accepts connections on. Setting the alias and the color is optional; making the alias valid UTF-8 is not, and any unused trailing bytes must be zero.
Thirty two bytes is a byte budget, not a character count. The field holds valid UTF-8, so a name in a script that spends several bytes per character fits fewer letters than a plain Latin one.
Renaming is cheap. A node must set each timestamp above the last, so a new name is just a fresh node_announcement that peers accept in place of the old record and queue for rebroadcast. There is no registry, no fee and no uniqueness check in the protocol.
The field is not free advertising space. BOLT 7 ignores announcements from nodes not already associated with a known channel, and no channel may be announced until its funding output has six confirmations, so a readable name costs an on chain transaction and locked capital before anyone relays it.
BOLT 7 carries a security section written specifically about aliases. Because they are user defined they are an injection vector while being rendered and while being stored, so implementers are told to sanitize them before putting them into HTML or JavaScript and to use prepared statements when persisting them. Software that shows one is also told to insinuate its self signed origin.
Where you see it
Node aliases surface anywhere the Lightning graph is drawn for a human.
BOLT 7 lets receiving software use the alias and the rgb_color to reference nodes in its interfaces, which is why a graph explorer or a peer picker shows a name rather than a key. A routing operator leans on that, since node_id is not something anyone types twice.
Whether you have one depends on what your wallet really is. Phoenix runs a real self contained Lightning node on the handset, so it holds an identity key and could announce a name. Wallet of Satoshi in custodial mode holds the keys on your behalf, so there is no node of yours in the graph and nothing to name.
Nothing you pay or receive depends on the name: invoices, routes and channel opens all key on node_id.
Node alias vs Lightning address
A node alias names a machine, while a Lightning address names a place to ask for an invoice. You cannot pay an alias: it carries no domain, no endpoint and no amount, and nothing in the protocol resolves it to anything payable. A Lightning address does the opposite job, resolving over HTTPS and handing your wallet a real invoice.
Node alias vs short channel ID
A short channel ID is the eight byte locator for a channel's funding output, and BOLT 7 also lets a peer hand out an alias short channel ID to stand in for it. That second alias shares nothing with a node alias except the word. A node may send a channel_update for a channel that has not been announced, with short_channel_id set to an alias its peer supplied rather than the real one, and it must set dont_forward and never pass that update on, for privacy reasons. One alias is a public name a node wants seen, the other a private substitute for a number a node wants hidden.