Glossary / Lightning & layer 2
Feature bit
- What is a feature bit?
- A feature bit tells other Lightning nodes that your node supports one specific protocol extension, with odd numbers marking it optional and even numbers marking it mandatory.
Lightning carries no version number for peers to compare, so two nodes work out what they can do together by trading a bitfield the moment they connect. BOLT 9 assigns 25 named pairs, running from bit 0 up to bit 67, and nobody may set both bits of a single pair. If your wallet refuses an invoice another wallet pays, a missing feature bit is one thing to check.
How it works
Feature bits are counted from the least significant bit of a bitfield, starting at bit 0, which has the value 0x1 and counts as even.
They are handed out in pairs, and the pairing is the whole trick: the odd bit means the node supports the feature, the even bit means it requires the feature. A capability can therefore ship as optional, spread quietly, and later be upgraded to compulsory, which BOLT 9 says outdated nodes will refuse, so the mismatch surfaces when two nodes meet rather than mid-payment. The requirements say the rest plainly: an origin node must not set both bits of a pair, and a receiving node that sees both anyway treats the feature as mandatory.
Some features rest on others, and the sender carries the whole chain. Basic multi-part payments occupy bits 16 and 17 and depend on payment_secret; zeroconf channels occupy 50 and 51 and depend on option_scid_alias; option_onion_messages_only_channels at 66 and 67 depends on ordinary onion messages. The origin node must set every transitive dependency, so code behind a single feature gate can assume the supporting bits are present rather than revalidating them.
Five of the 25 pairs now read only ASSUMED: 0/1, 8/9, 12/13, 14/15 and 44/45. Each became so widespread that every node is assumed to have it, and the semantics survive only in earlier revisions of the specification. The table skips numbers too, with nothing assigned at 2/3, 20/21, 30/31, 32/33, 52 through 59 or 64/65, so gaps are ordinary.
Where you see it
Feature bits travel in several separate places, and the BOLT 9 table's Context column names which of them each pair belongs in, blank on six of the 25 rows.
I marks the init message two peers exchange on connecting, N a node_announcement broadcast into the gossip graph, C a channel_announcement, 9 a BOLT 11 invoice, B the allowed_features field of a blinded path, and T the channel_type agreed when a channel is opened. Plenty of bits appear in one context only: option_payment_metadata, bits 48 and 49, is invoice only, while option_anchors at 22 and 23 appears in init, in gossip and as a channel type but never in an invoice.
Where two contexts disagree, the invoice wins: BOLT 9's rationale states that for flags carried in both node_announcement and BOLT 11, the invoice values override the announced ones. That is why a wallet reads capabilities off the invoice you pasted, not off what the destination advertised to the gossip network hours earlier.
Phoenix, built by ACINQ on its Eclair implementation, runs a real node on your phone, so whether it accepts a multi-part payment or a blinded route is settled by a bitfield swapped with its peer, not by a marketing page. Muun shows on-chain and Lightning as one balance, and its Lightning payments still come down to the bits in the invoice.
Feature bit vs version bit
A feature bit negotiates capability between two Lightning peers; a version bit signals a soft fork in a bitcoin block header. BIP-9 gives miners bits 0 through 28 of the header's version field and locks a deployment in at 1,916 of a 2,016 block window on mainnet, after which it is active for every block that follows. A feature bit binds nobody: it is a claim between two peers, true on one connection and false on the next, with no threshold, no timeout and no network-wide activation. Lightning negotiates what a pair of nodes will do for each other; bitcoin decides what everyone must accept.