Skip to content

Flat features#1253

Merged
t-bast merged 9 commits intomasterfrom
flat-features
Jan 9, 2020
Merged

Flat features#1253
t-bast merged 9 commits intomasterfrom
flat-features

Conversation

@t-bast
Copy link
Member

@t-bast t-bast commented Dec 12, 2019

This PR implements lightning/bolts#666

I removed the awkward --allowMultiPart API parameter to instead rely on nodeParams.features.
This feels cleaner and is how we'll integrate Trampoline support too.

Note that when we update our nodes, we'll need to update our reference.conf:

  • change the features format
  • update our features to advertise MPP support

Compatibility tests:

  • With old eclair nodes, advertizing MPP and PaymentSecret: ok
  • With c-lightning master: ok
  • With lnd v0.8.2-beta: ok

Not done in this PR (and should probably be done at some point):

  • real support for turning off features (e.g. if I turn off MPP, I should use a legacy PayFSM)
  • better typing to indicate which feature bits go in Init vs ChannelAnn vs NodeAnn vs Invoice

@codecov-io
Copy link

codecov-io commented Dec 12, 2019

Codecov Report

❗ No coverage uploaded for pull request base (master@ea7abd9). Click here to learn what that means.
The diff coverage is 80.95%.

@@            Coverage Diff            @@
##             master    #1253   +/-   ##
=========================================
  Coverage          ?   77.11%           
=========================================
  Files             ?      142           
  Lines             ?     9892           
  Branches          ?      394           
=========================================
  Hits              ?     7628           
  Misses            ?     2264           
  Partials          ?        0
Impacted Files Coverage Δ
...la/fr/acinq/eclair/payment/relay/NodeRelayer.scala 97.59% <100%> (ø)
...rc/main/scala/fr/acinq/eclair/io/Switchboard.scala 80% <100%> (ø)
...c/main/scala/fr/acinq/eclair/channel/Channel.scala 83.1% <73.07%> (ø)
...in/scala/fr/acinq/eclair/channel/Commitments.scala 90.74% <87.5%> (ø)

@t-bast t-bast marked this pull request as ready for review December 13, 2019 10:13
@t-bast
Copy link
Member Author

t-bast commented Dec 17, 2019

I took this opportunity to re-work Features.scala to properly type things.
We're now stricter on features dependencies, as described here.

Copy link
Member

@pm47 pm47 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice change, a few nits, didn't review the tests yet.

For Init I disagree with your approach of changing the type instead of the codec. If you figure it out we could probably do the same for LocalParams/NodeParams.

@t-bast
Copy link
Member Author

t-bast commented Dec 18, 2019

I fixed the nits in aee1472.

For Init I disagree with your approach of changing the type instead of the codec. If you figure it out we could probably do the same for LocalParams/NodeParams.

I'll investigate that.

Implement lightning/bolts#666

We keep the global/local split in Commitments to avoid backwards
incompatibility in the codec.
We instead rely on the MPP feature being set in nodeParams.
That means MPP-enabled nodes need to update their reference.conf.
Add types to allow cleaner dependency validation.
Most of the time we don't care whether a feature is activated as
optional or mandatory, which caused duplicate code.
This is now handled more cleanly.

It also paves the way to annotate features with the places they
should be advertised (Init vs NodeAnn vs ChannelAnn vs invoice).
This allows us to drop the global/local fields from the codebase.
They are handled directly at the wire level.
trampoline-payments-enable = false // TODO: @t-bast: once spec-ed this should use a global feature flag
global-features = "0200" // variable_length_onion
local-features = "088a" // initial_routing_sync + option_data_loss_protect + option_channel_range_queries + option_channel_range_queries_ex
features = "0a8a" // initial_routing_sync + option_data_loss_protect + option_channel_range_queries + option_channel_range_queries_ex + variable_length_onion
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should use a completely different method, using rfcName field:

features {
  option_data_loss_protect = "mandatory"
  initial_routing_sync = "optional"
  gossip_queries = "mandatory"
  ...
} 

Less error prone and more readable, but also less flexible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would also affect the override-features attribute...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a good idea if we really want to allow users to turn some features on and off.
The problem is there are quite a few features that we can't really turn off right now (some code paths will ignore the fact that a feature is turned off and still use it).
I think it makes sense to do that change once we've worked on making sure the code base really allows completely turning off all features.

@t-bast t-bast requested review from pm47 and sstone January 9, 2020 08:27
@t-bast t-bast merged commit 72338ab into master Jan 9, 2020
@t-bast t-bast deleted the flat-features branch January 9, 2020 12:47
dpad85 added a commit that referenced this pull request Jan 10, 2020
Due to changes in the features system (#1253), feature graph
validation would fail with legacy 1.0.1 phoenix wallet. This check
should be disabled as long as there are 1.0.1 Phoenix wallet in
the wild.
dpad85 added a commit that referenced this pull request Jan 10, 2020
Due to changes in the features system (#1253), feature graph
validation would fail with legacy 1.0.1 Phoenix wallet. This check
should be disabled as long as there are 1.0.1 Phoenix wallet in
the wild.
dpad85 added a commit that referenced this pull request Jan 21, 2020
Due to changes in the features system (#1253), feature graph
validation would fail with legacy 1.0.1 Phoenix wallet. This check
should be disabled as long as there are 1.0.1 Phoenix wallet in
the wild.

(cherry picked from commit 9f8f8e4)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants