Feature Bits 功能位

Feature Bit Encoding Rules

Each feature uses a consecutive pair of bits:

Bit 2N (even): Compulsory support
  -> If peer doesn't support, must disconnect

Bit 2N+1 (odd): Optional support
  -> If peer doesn't support, can still connect

Example: data_loss_protect (feature 0/1)

Bit 0 (even) set to 1:
• Means: I require this feature
• Result: Peer must support, otherwise disconnect

Bit 1 (odd) set to 1:
• Means: I optionally support this feature
• Result: Use if peer also supports

Feature Bit Vector (from low to high bits):
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11| ...
|-------|-------|-------|-------|-------|-------|
|Feat 0 |Feat 1 |Feat 2 |Feat 3 |Feat 4 |Feat 5 | ...

Feature Bits Appear in Different Contexts

Context     | Message/Location       | Usage
------------|------------------------|------------------
init (I)    | init message           | Node connection
node (N)    | node_announcement      | Network gossip
channel (C) | channel_announcement   | Channel gossip
invoice (9) | BOLT 11 invoice        | Payment request
bolt12 (B)  | BOLT 12 offer/invoice  | Offer system

Different contexts have different feature subsets:
• init: All node features
• node: Features to announce for node
• channel: Channel-specific features
• invoice: Payment-related features
• bolt12: Offer-related features

BOLT 9 定義的功能列表：

位元   名稱                          上下文    狀態
─────────────────────────────────────────────────────────
0/1    option_data_loss_protect      IN        已棄用(v0.1)
4/5    option_upfront_shutdown_script IN
6/7    gossip_queries                IN
8/9    var_onion_optin               IN9       必須(v0.1)
10/11  gossip_queries_ex             IN
12/13  option_static_remotekey       IN        已棄用(v0.1)
14/15  payment_secret                IN9       必須(v0.1)
16/17  basic_mpp                     IN9
18/19  option_support_large_channel  IN
20/21  option_anchor_outputs         IN        已棄用
22/23  option_anchors_zero_fee_htlc_tx IN
24/25  option_route_blinding         IN9
26/27  option_shutdown_anysegwit     IN
28/29  option_dual_fund              IN
30/31  option_amp                    IN9
38/39  option_onion_messages         IN
44/45  option_channel_type           IN
46/47  option_scid_alias             IN
48/49  option_payment_metadata       9
50/51  option_zeroconf               IN
52/53  option_trampoline_routing     IN9
54/55  option_simple_close           IN        

Feature Negotiation on Connection

Alice                                 Bob
  |                                    |
  |-------- init --------------------->|
  |         features: 0x02aaa2         |
  |                                    |
  |<------- init ----------------------|
  |         features: 0x028a2a         |
  |                                    |
  | [Calculate commonly supported]     |
  |                                    |

Feature Bit Comparison:
Alice: 0x02aaa2 = 0000 0010 1010 1010 1010 0010
Bob:   0x028a2a = 0000 0010 1000 1010 0010 1010

Analysis:
• Feature 0/1 (data_loss_protect): Both support
• Feature 4/5 (upfront_shutdown): Alice has, Bob doesn't
• Feature 8/9 (var_onion): Both support
• ...

Result: Use mutually supported features

Compulsory Feature Check:
• If peer lacks our required compulsory feature (even bit):
  -> Disconnect

• If peer has compulsory feature we don't recognize (even bit):
  -> Disconnect

• Optional feature (odd bit) mismatch:
  -> Continue connection, but don't use that feature

查看節點支援的功能：

LND:
# 查看本地節點功能
lncli getinfo | jq '.features'

# 查看遠端節點功能
lncli getnodeinfo <pubkey> | jq '.node.features'

CLN:
# 查看本地節點
lightning-cli getinfo | jq '.our_features'

# 查看遠端節點
lightning-cli listnodes <node_id> | jq '.[0].features'

輸出示例：
{
  "0": { "name": "data-loss-protect", "is_required": false, "is_known": true },
  "5": { "name": "upfront-shutdown-script", "is_required": false, "is_known": true },
  "9": { "name": "var-onion-optin", "is_required": false, "is_known": true },
  "15": { "name": "payment-addr", "is_required": false, "is_known": true },
  "17": { "name": "multi-path-payments", "is_required": false, "is_known": true },
  "23": { "name": "anchors-zero-fee-htlc-tx", "is_required": false, "is_known": true },
  "45": { "name": "explicit-channel-type", "is_required": false, "is_known": true }
}

option_channel_type (44/45)

Problem: Implicit channel type negotiation may cause inconsistency
Solution: Explicitly specify channel type when opening channel

channel_type in open_channel message:
channel_type TLV:
  -> Contains feature bit vector for channel to use

Example channel types:
• Basic channel: No special features
• static_remotekey: option_static_remotekey
• anchor: option_anchors_zero_fee_htlc_tx
• anchors+scid_alias: above + option_scid_alias
• Zero-conf anchor: + option_zeroconf

Negotiation flow:
1. Initiator proposes channel_type in open_channel
2. Receiver confirms or proposes alternative in accept_channel
3. Both agree, then use that type
4. Type doesn't change during channel lifetime

BOLT 11 Invoice Feature Bits

Invoices can include "9" tag to specify feature requirements:
lnbc...
  9 = feature bits

Common invoice features:
• var_onion_optin (8/9): Must use TLV onion
• payment_secret (14/15): Must include payment_secret
• basic_mpp (16/17): Accept MPP
• amp (30/31): Accept AMP

Sender handling:
• Check invoice feature bits
• If unrecognized compulsory feature -> Cannot pay
• If supports optional feature -> Use that feature
• Build payment conforming to feature requirements