⚡ Lightning Feature Decoder

Decode Lightning Network node feature flags based on BOLT #9

Understanding how Lightning nodes communicate their capabilities through feature bit flags

GitHub Repository

📚 How Feature Flag Decoding Works

Feature flags in Lightning Network are used to communicate which features a node supports. They follow the BOLT #9 specification and use a binary flag system where each feature is assigned a pair of bits.

🔢 The Bit Pairing System

  • Even bits (0, 2, 4, 6...): Indicate the feature is mandatory/required
  • Odd bits (1, 3, 5, 7...): Indicate the feature is optional
  • Principle: "It's OK to be odd" - nodes ignore unknown odd bits but disconnect on unknown even bits

🔄 Decoding Process

The feature string is a hexadecimal representation that gets converted to binary. Bits are counted from the right (LSB = bit 0):

Example: "0252a1" hex → "100101001010100001" binary Bit positions: ←17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0→ Binary: 1 0 0 1 0 1 0 0 1 0 1 0 1 0 0 0 0 1 Reading from right to left: - Bit 0 (even) = 1 → option_data_loss_protect is MANDATORY - Bits 4/5: Bit 5 (odd) = 1 → option_upfront_shutdown_script is OPTIONAL - Bits 8/9: Bit 8 (even) = 1 → var_onion_optin is MANDATORY

📋 Feature Status Types

  • 🔴 REQUIRED: Even bit set - peer must support this feature
  • 🟡 OPTIONAL: Odd bit set - peer can choose to support this
  • 🟢 ASSUMED: Feature is so common it's assumed present by all modern nodes
  • ⚪ NOT SUPPORTED: Neither bit set - node doesn't support this feature

Try these examples: