Fabrice Drouin writes:
> On Mon, 21 Jan 2019 at 08:05, Rusty Russell 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 ?)
The most obvious one is a change to scriptless scripts, but any other
change from preimage to secret exchange would have the same properties.
You both need to know what nodes support it (if you want to use it), and
what nodes require it (if you don't).
Similarly, any kind of mid-path splitting or combining feature.
It's unusual, though, which is why we don't have any yet.
> 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)
You misunderstand. You can put the even feature into peer_features on
connect (as now), but you only put the odd feature into node_announce.
That way, even if I don't understand the feature I can still route
through you, which is correct. If I try to connect to you I find out
that you have an unknown feature.
The alternative is to put a second bitmap (peer_features) into
node_announcement, of course. But since we were discussing combining
the feature bits, this seemed the way to make it work.
Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
