[Lightning-dev] Approximate assignment of option names: please fix!

Pierre pm+lists at acinq.fr
Tue Nov 13 12:47:54 UTC 2018

Hi Rusty,

>        The feature masks are split into local features (which only
>        affect the protocol between these two nodes) and global features
>        (which can affect HTLCs and are thus also advertised to other
>        nodes).

I don't think that definition makes a lot of sense. For example I
probably want to advertise the fact that my node supports
option_data_loss_protect, which is a local feature. OTOH why would I
*not* want to avertise a feature that I support? I struggle to see
what is the point of making the distinction between local/global

Also, as ZmnSCPxj pointed out in his Wumbo-related post, just because
I support a feature doesn't mean that I want to apply it to any peer
that connects to my node. Since we can't advertise our whitelist or
whatever logic we use to enable a given feature for a particular node,
we can only be sure that a feature will be enabled by connecting to
the peer and seeing what's in the init message.

So how about just getting rid of the global/local distinction (I think
this can be done in a backward-compatible way), and use the following
- in the node_announcement message, have a node_features that
describes features my node supports/requires
- in the init message, have a connection_features that are set for
this particular connection.

Obviously node_features/connection_features are related and must
"match", in the sense that node_features constrains
connection_features, particularly if we use things like
option_anyone_can_wumbo (again referring to ZmnSCPxj's post).



More information about the Lightning-dev mailing list