Module features

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 as indicated in some messages. 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).
• 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).
• AnchorsZeroFeeHtlcTx - requires/supports that commitment transactions include anchor outputs and HTLC transactions are pre-signed with zero fee (see BOLT-3 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

• BlindedHopFeatures
  Features used within BOLT 4 encrypted_data_tlv and BOLT 12 blinded_payinfo
• Bolt11InvoiceFeatures
  Features used within an invoice.
• Bolt12InvoiceFeatures
  Features used within an invoice.
• ChannelFeatures
  Features used within a channel_announcement message.
• ChannelTypeFeatures
  Features used within the channel_type field in an OpenChannel message.
• InitFeatures
  Features used within an init message.
• InvoiceRequestFeatures
  Features used within an invoice_request.
• NodeFeatures
  Features used within a node_announcement message.
• OfferFeatures
  Features used within an offer.