On Mon, 21 Jan 2019 at 08:05, Rusty Russell <ru...@rustcorp.com.au> wrote: > > Hi all, > > I have a concrete proposal for feature bits. > > 1. Rename 'local features' to 'peer features'. > 2. Rename 'global features' to 'routing features'. > 3. Have them share a number space (ie. peer and routing features don't > overlap). > 4. Put both in `features` in node announcements, but never use even bits > for peer features. > > This means we can both use node_announcement as "connect to a peer which > supports feature X" and "can I route through this node?".
Unification of feature bits makes sense but I don't really understand the concept of `routing features` as opposed to `node features`. What would prevent us from routing payments through a node ? (AMP ? changes to the onion packet ?) I find it easier to reason in terms of `node features`, which are advertised in node announcements, and `peer/connection features`, which are a subset of `node features` applied to a specific connection. Node features would be all the features that we have today (option_data_loss_protect, initial_routing_sync, option_upfront_shutdown_script, gossip_queries), since it makes sense to advertise them except maybe for initial_routing_sync, with the addition of wumbo which could only be optional. What is the rationale for not allowing even bits in peer features ? It makes sense for node features, but there are cases where you may require specific features for a specific connection (option_data_loss_protect for example, or option_upfront_shutdown_script) Cheers, Fabrice > Similarly, (future) DNS seed filtering might support filtering only by > pairs of bits (ie. give me peers which support X, even or odd). > > Cheers, > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
