[Lightning-dev] Unification of feature bits?

Fabrice Drouin fabrice.drouin at acinq.fr
Fri Jan 25 16:55:19 UTC 2019


On Mon, 21 Jan 2019 at 08:05, Rusty Russell <rusty at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


More information about the Lightning-dev mailing list