From pm+lists at acinq.fr Tue Nov 13 12:47:54 2018 From: pm+lists at acinq.fr (Pierre) Date: Tue, 13 Nov 2018 13:47:54 +0100 Subject: [Lightning-dev] Approximate assignment of option names: please fix! In-Reply-To: <87o9atrh59.fsf@rustcorp.com.au> References: <87o9atrh59.fsf@rustcorp.com.au> Message-ID: 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