Module breez_sdk_core::lightning::ln::features
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 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. Calledoption_support_large_channel
in the spec. (see BOLT-2 for more information).ShutdownAnySegwit
- requires/supports that future segwit versions are allowed inshutdown
(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 theKeysend
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§
- Tracks the set of features which a node implements, templated by the context in which it appears.
Type Aliases§
- Features used within BOLT 4 encrypted_data_tlv and BOLT 12 blinded_payinfo
- Features used within an invoice.
- Features used within an
invoice
. - Features used within a
channel_announcement
message. - Features used within the channel_type field in an OpenChannel message.
- Features used within an
init
message. - Features used within an
invoice_request
. - Features used within a
node_announcement
message. - Features used within an
offer
.