lukechilds
/
lightning-docs
mirror of https://github.com/lukechilds/lightning-docs.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
33 Commits
3 Branches
0 Tags
210 KiB
 
Branch: master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'master'
${ noResults }
lightning-docs/feature-flags.md

7.0 KiB
Raw Permalink Blame History

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

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

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

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.