7.0 KiB
Lightning feature flags: from Zero to Hero
This article describes optional lightning features that nodes can turn on and off. Nodes actively tell the whole network about the features they support, to help peers looking for specific features connect to them.
data_loss_protect
This flag allows a node to detect upon channel reestablishment that it has lost state (i.e. thinks a state is 'current' while it has been superseded and maybe even revoked). This works because the commitment point (that is added with this flag) can be verified to be authentically derived from the secret, so the 'forgetful' node must have sent it to them before it lost its commitment point counter state.
The node that receives the channel_reestablish
could also just pretend that it has lost state, and e.g. drop the connection after receiving channel_reestablish
, tempting the peer to close with a revoked state that it thinks the pretender can't punish. But tempting a cheating node is better for an honest node, than entering into a Lightning peer connection, which would eventually get forced closed because of a commitment mismatch. At that point, a cheater knows with certainty that the 'forgetful' node is not bluffing, so the attack odds are better.
Accepted in November 2017: meeting log
This option is required by most implementations, e.g. LND: brontide.go:2749.
upfront_shutdown_script
This makes a channel party commit to a scriptpubkey
(output locking script) upon opening of a channel. In a cooperative close, without this flag, the funds are sent to an address chosen upon closing. This flag can increase security somewhat, since even an attacker with the channel keys may not have the keys of the address controlling the chosen scriptpubkey
.
Implementations
- Electrum: since this PR from January 2021, most likely part of v4.1.
- C-Lightning: since v0.7.3 from November 2019
- LND: since this PR merged in December 2019, part of v0.9.0 from January 2020 according to release notes.
- Eclair: since this PR merged in July 2121
gossip_queries
and gossip_queries_ex
gossip_queries
enables:
- a
query_short_channel_ids
message such that a node can request gossip for given list of short channel IDs. - a
query_channel_range
message such that a node can request channel updates from a specified block range. - a
gossip_timestamp_filter
message that a node must use to signal the range of the channel updates it is interested in, filtered by their timestamp.
gossip_queries_ex
adds timestamps and checksums to query_channel_range
replies.
Implementations of gossip_queries_ex
- Eclair: since this PR merged in October 2019, part of v0.3.2 according to branch tags on Github.
- C-Lightning: since this PR merged in September 2019, part of v0.7.3 according to branch tags on GitHub.
- LND:
gossip_queries
supported since this PR merged in May 2018, part of v0.5.
static_remote_key
This removes key-rotation from the to_remote
output. This means that the to_remote
output of every commitment transaction can be spent by the same key. If you lose channel state, this will allow you to claim your balance when the counterparty closes. Without this option, you'd have to grind and see which key matches. Watchtowers are also easier to implement with this.
Implementations
- C-Lightning: since this PR from September 2019, part of v0.7.3 according to the milestone there.
- Eclair: since this PR merged in June 2020, part of v0.5.0 according to branch information
- LND: since v0.8.0 from October 2019. LND requires this option for new channels: brontide.go:2790
- Electrum requires this for all peers since 4.0.1 from July 2020
payment_secret
Merged in July 2019 as part of MPP: https://github.com/lightningnetwork/lightning-rfc/pull/643
The feature prevents probing attacks as noted in BOLT-11.
You can use payment_secret without necessarily using MPP, though it is a requirement for MPP.
Implementations
- C-Lightning: since at least v0.8.0 from December 2019, since that version supports receiving MPP
- Eclair: since at least this PR from October 2019, released with MPP (see below)
- Electrum: sent/accepted since 4.0.1 from July 2020
- LND: supported since v0.10.0 (see below), required in incoming payments since v0.12.0 (unreleased as of January 7th, 2020): All generated invoices will include the
s
field.
basic_mpp
(multi-part payments)
This splits a payment into multiple pieces, that all have the same payment hash (so it is vulnerable to a straddling attack). This means that the theoretical maximum payment amount can be higher. A receiver doesn't know how many parts a payment is split into. To avoid an attack where one part the MPP payment will never arrive and the HTLC consumes resources over too long, receivers must fail incoming HTLCs after a reasonable timeout, usually 60 seconds.
Implementations
All listed implementations that have send support, also have receive support.
- C-Lightning: Send support since v0.9.0 from July 2020
- Eclair: Send support since v0.3.3 from January 2020, see also wiki page.
- LND: Send support since v0.10.0 from April 2020