Module lightning_types::features

source ·
Expand description

Feature flag definitions for the Lightning protocol according to BOLT #9.

Lightning nodes advertise a supported set of operation through feature flags. Features are applicable for a specific context. Features encapsulates behavior for specifying and checking feature flags for a particular context. Each feature is defined internally by a trait specifying the corresponding flags (i.e., even and odd bits).

Whether a feature is considered “known” or “unknown” is relative to the implementation, whereas the term “supports” is used in reference to a particular set of Features. That is, a node supports a feature if it advertises the feature (as either required or optional) to its peers. And the implementation can interpret a feature if the feature is known to it.

The following features are currently required in the LDK:

  • VariableLengthOnion - requires/supports variable-length routing onion payloads (see BOLT-4 for more information).
  • StaticRemoteKey - requires/supports static key for remote output (see BOLT-3 for more information).

The following features are currently supported in the LDK:

  • DataLossProtect - requires/supports that a node which has somehow fallen behind, e.g., has been restored from an old backup, can detect that it has fallen behind (see BOLT-2 for more information).
  • InitialRoutingSync - requires/supports that the sending node needs a complete routing information dump (see BOLT-7 for more information).
  • UpfrontShutdownScript - commits to a shutdown scriptpubkey when opening a channel (see BOLT-2 for more information).
  • GossipQueries - requires/supports more sophisticated gossip control (see BOLT-7 for more information).
  • PaymentSecret - requires/supports that a node supports payment_secret field (see BOLT-4 for more information).
  • BasicMPP - requires/supports that a node can receive basic multi-part payments (see BOLT-4 for more information).
  • Wumbo - requires/supports that a node create large channels. Called option_support_large_channel in the spec. (see BOLT-2 for more information).
  • AnchorsZeroFeeHtlcTx - requires/supports that commitment transactions include anchor outputs and HTLC transactions are pre-signed with zero fee (see BOLT-3 for more information).
  • RouteBlinding - requires/supports that a node can relay payments over blinded paths (see BOLT-4 for more information).
  • ShutdownAnySegwit - requires/supports that future segwit versions are allowed in shutdown (see BOLT-2 for more information).
  • OnionMessages - requires/supports forwarding onion messages (see BOLT-7 for more information).
  • ChannelType - node supports the channel_type field in open/accept (see BOLT-2 for more information).
  • SCIDPrivacy - supply channel aliases for routing (see BOLT-2 for more information).
  • PaymentMetadata - include additional data in invoices which is passed to recipients in the onion. (see BOLT-11 for more).
  • ZeroConf - supports accepting HTLCs and using channels prior to funding confirmation (see BOLT-2 for more info).
  • Keysend - send funds to a node without an invoice (see the Keysend feature assignment proposal for more information).
  • Trampoline - supports receiving and forwarding Trampoline payments (see the Trampoline feature proposal for more information).

LDK knows about the following features, but does not support them:

  • AnchorsNonzeroFeeHtlcTx - the initial version of anchor outputs, which was later found to be vulnerable (see this mailing list post for more information).

Structs§

  • Features
    Tracks the set of features which a node implements, templated by the context in which it appears.

Type Aliases§