Feature bit unification and renaming

[rustyrussell]

This is 5 commits, each standalone:

1. Rename "local" to "node" features, "global" to "channel" features. The original idea was that
   "local" features only affect direct peers. That still stands, but the new names are clearer.
   Note: There are still no "channel" features defined.
2. Note that features share the same number space, needed for minor: updated open channel diagram #5.
3. Remove init message requirement to disconnect on unknown channelfeatures. This just
   means you can't open a channel. Unknown node features means you can't even talk.
4. Explicitly mirror channelfeatures in channel_announcement. These are things you might need to
   know to use that specific channel, or might be required, depending on the feature itself. Removes
   the "don't relay these if they have an unknown feature" rule.
5. Explicitly mirror what channelfeatures we support in node_announcement (usually as optional
   features, of course). This lets you find nodes with specific features.

Concrete Examples

Consider a node which supports a d-log-HTLC channel, and doesn't support legacy HTLCs on that channel:

1. This is clearly a channelfeature.
2. It may have negotiated this with the peer as an optional or required feature.
3. It must advertize this in channel_announcement as a required feature, since you need to understand it to use the channel at all.
4. It gets advertized in node_announcement, as required or optional, depending on 2 above.

Now, consider a node which can create wumbo (> 2^24 satoshi) channels:

1. This is a nodefeature.
2. It's (presumably) optional.
3. It doesn't appear in channel_announcement.
4. It gets advertized in node_announcement, as (presumably) optional.

Finally, consider a node which can handle wumbo HTLCs:

1. This is a channelfeature.
2. It's (presumably) optional.
3. It gets advertized in channel_announcement as optional, since you don't need to understand it.
4. It gets advertized in node_announcmenet, as (presumably) optional.

[t-bast]

I think this is a good clarification.
ACK from me for next meeting.

[t-bast]

As discussed in the IRC meeting, people still find the names confusing so here are my suggestions, I'll let the consensus judge if they're better or worse ;)

• Suggestions for renaming local features
  • connection or conn features (since it only impacts people I'm connected to)
  • peer features (it only impacts my direct peers)
  • neighbour or neighbor features (meh)
  • keep local (I honestly think local is a good name, it's more the global part that I found a bit misleading)
• Suggestions for renaming global features
  • network features (they are interesting to the whole network)
  • routing features (if we assume that routing is the only thing we're using remote nodes for - not sure if that will always be true)
  • remote features (meh)

I'll edit this comment if I have other ideas.

[rustyrussell]

I like local and routing features, TBH.

[Roasbeef]

Thanks for those examples! I understand the underlying motivation now after reading through them. As for names, my vote goes for node features (former global) and link features.

[Roasbeef]

It seems the only "pure" link feature we have is initial-routing-sync, the rest can lie in either domain.

[t-bast]

As for names, my vote goes for node features (former global) and link features.

I think node is confusing. Rusty proposed it to replace the current local and you're now proposing it to replace the current global. That clearly indicates that it's misleading, doesn't it? :)

I also think that link is confusing, I can see arguments for using it to replace either local or global...
Because it could mean that it defines properties of your local links (channels?) so it's a local feature, or it's a global feature because it defines properties that remote non-neighbor nodes should know about your links (channel?).

[cfromknecht]

As discussed on IRC, the naming that makes the most sense to me personally is:

• global -> node: functionally equivalent to service bits in bitcoin, apart from the fact that they are gossiped. Emphasize that the features are applicable to the node as a whole (depending on the feature, that it applies to all of a node's channels), e.g. can this node: support variable frame onions, extended gossip queries, DLP, link-level payment sharding, etc.
• local -> connection: emphasizes that these feature bits are only applied for the duration of the connection, and may change upon a subsequent reconnect, e.g. will this connection: allow funding wumbo channels, extended gossip queries, DLP, etc.

To me routing is too specific, as there are already several features that could be advertised that have nothing to do with routing (and we are likely to add more in the future). local is okay, but it's a little ambiguous what that means and could be clearer.

[cfromknecht]

unification changes look pretty good, maybe still some bikeshedding to be done on naming tho :) i have a few other questions i've left inline

[cfromknecht]

this seems like a good change, we probably shouldn't be forwarding messages that we were unable to parse

[cfromknecht]

if i understand correctly, this will removes the ability to partition the gossip network as a result of nodes not understanding an even feature bit? do we still want to retain the ability to do so via unknown TLV types?

[rustyrussell]

Hmm, that's an excellent question! I... don't know. Allowing "invalid" TLVs to propagate seems like a burden on implementations, but maybe it's a feature somehow?

[cfromknecht]

In due time we may discover, I see arguments for both sides 🤷‍♂️

[t-bast]

I quite like renaming local to connection (seems like we all have a rough agreement on that one).
I'm not completely convinced by node to replace global but my best proposal (network) isn't perfect either, so I could live with it.

[Roasbeef]

node+connection SGTM!