From corne at bitonic.nl  Tue Nov 27 15:54:27 2018
From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=)
Date: Tue, 27 Nov 2018 16:54:27 +0100
Subject: [Lightning-dev] Approximate assignment of option names: please
 fix!
In-Reply-To: <87tvkkh6zq.fsf@rustcorp.com.au>
References: <87o9atrh59.fsf@rustcorp.com.au>
	<CAMXsxZOPkCcTzkoU7ZJfHPHhVK80-cv+XBztGdYFs9vV46qyZg@mail.gmail.com>
	<87tvkkh6zq.fsf@rustcorp.com.au>
Message-ID: <84294c1f-9c34-9827-0c1d-9872f8260c16@bitonic.nl>

The only reasons I see for keeping the global/local distinction is that
you might not want to gossip everything, either to keep the gossip data
small, or for some privacy reasons. Apparently, that's all very
theoretical so far, as current features don't seem to need either.


Ideally you'd like to have a design that requires as little consensus as
possible, but for global feature bits it's clear there has to be
consensus about their meaning. For a moment I thought we'd have more
relaxed requirements for local feature bits (as only peers have to agree
on feature bit meanings), but if we want every peer to be able to
connect to every other peer, we still need global consensus on the
meaning of local feature bits.


I'm not even sure it makes sense to keep certain feature bits local for
privacy reasons. Interested parties can usually just figure out your
local feature bits by connecting to your node. As for the size of gossip
data: the bits themselves shouldn't be the problem. Certain features
might require extra data to be gossiped, but that should be discussed on
a case-by-case data per feature. We might end up with a gossip design
where you'd first receive the basic gossip data, and then try to get
extended data you're interested in, based on what feature bits are
enabled in the basic gossip data.


So, maybe I missed something important, but no, right now I don't see a
good reason for the global/local distinction.


CJP


On 14-11-18 00:50, Rusty Russell wrote:
> Pierre <pm+lists at acinq.fr> writes:
>> 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.
> The theory was that local features concern direct peers, global features
> concern others (thus *must* be advertized by gossip).
>
> I *expected* local features to become ubiquitous over time, so by the
> time an implementation decided "I don't even want to talk to nodes
> without feature X" then most nodes would support feature X, so you could
> simply connect and you're probably OK.
>
> So the question becomes:
>
> 1. Do people want to pre-filter by local features?
> 2. If so, only some local features, or all of them?
>
> If only some, then we make those ones global features.  If all, then we
> remove the local/global distinction altogether?
>
> Thanks,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev