Pierre [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-13 📝 Original message: Hi Rusty, > The feature ...

📅 Original date posted:2018-11-13
📝 Original message:
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
actually.

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
instead:
- 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).

Cheers,

Pierre