From rusty at blockstream.com  Tue Nov 13 23:50:49 2018
From: rusty at blockstream.com (Rusty Russell)
Date: Wed, 14 Nov 2018 10:20:49 +1030
Subject: [Lightning-dev] Approximate assignment of option names: please
	fix!
In-Reply-To: <CAMXsxZOPkCcTzkoU7ZJfHPHhVK80-cv+XBztGdYFs9vV46qyZg@mail.gmail.com>
References: <87o9atrh59.fsf@rustcorp.com.au>
	<CAMXsxZOPkCcTzkoU7ZJfHPHhVK80-cv+XBztGdYFs9vV46qyZg@mail.gmail.com>
Message-ID: <87tvkkh6zq.fsf@rustcorp.com.au>

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.