📅 Original date posted:2018-11-27
📝 Original message:
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
Corné Plooy [ARCHIVE] /
npub1ly…cdx6n
2023-06-09 12:52:38
in reply to nevent1q…hzrg
Author Public Key
npub1ly5vrg5ylhdkxrkj824jhlnfsy2z8fvlg8wcc0jqc4aezma6majsycdx6nPublished at
2023-06-09 12:52:38Event JSON
{
"id": "f6b973417e03363369556e1eba264aa7759e6210f6597b72d1fc3548c88586d9",
"pubkey": "f928c1a284fddb630ed23aab2bfe69811423a59f41dd8c3e40c57b916fbadf65",
"created_at": 1686315158,
"kind": 1,
"tags": [
[
"e",
"7e19675ce2d9059ad28b8c6d674e5062c9c3e08808be8a20aebc7b4c921800e3",
"",
"root"
],
[
"e",
"cda4efa0e3aebd1721bc7d8de5d9bf8523df563ad174b2a240b4e5ceef4216a2",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-11-27\n📝 Original message:\nThe only reasons I see for keeping the global/local distinction is that\nyou might not want to gossip everything, either to keep the gossip data\nsmall, or for some privacy reasons. Apparently, that's all very\ntheoretical so far, as current features don't seem to need either.\n\n\nIdeally you'd like to have a design that requires as little consensus as\npossible, but for global feature bits it's clear there has to be\nconsensus about their meaning. For a moment I thought we'd have more\nrelaxed requirements for local feature bits (as only peers have to agree\non feature bit meanings), but if we want every peer to be able to\nconnect to every other peer, we still need global consensus on the\nmeaning of local feature bits.\n\n\nI'm not even sure it makes sense to keep certain feature bits local for\nprivacy reasons. Interested parties can usually just figure out your\nlocal feature bits by connecting to your node. As for the size of gossip\ndata: the bits themselves shouldn't be the problem. Certain features\nmight require extra data to be gossiped, but that should be discussed on\na case-by-case data per feature. We might end up with a gossip design\nwhere you'd first receive the basic gossip data, and then try to get\nextended data you're interested in, based on what feature bits are\nenabled in the basic gossip data.\n\n\nSo, maybe I missed something important, but no, right now I don't see a\ngood reason for the global/local distinction.\n\n\nCJP\n\n\nOn 14-11-18 00:50, Rusty Russell wrote:\n\u003e Pierre \u003cpm+lists at acinq.fr\u003e writes:\n\u003e\u003e Hi Rusty,\n\u003e\u003e\n\u003e\u003e\u003e The feature masks are split into local features (which only\n\u003e\u003e\u003e affect the protocol between these two nodes) and global features\n\u003e\u003e\u003e (which can affect HTLCs and are thus also advertised to other\n\u003e\u003e\u003e nodes).\n\u003e\u003e I don't think that definition makes a lot of sense. For example I\n\u003e\u003e probably want to advertise the fact that my node supports\n\u003e\u003e option_data_loss_protect, which is a local feature. OTOH why would I\n\u003e\u003e *not* want to avertise a feature that I support? I struggle to see\n\u003e\u003e what is the point of making the distinction between local/global\n\u003e\u003e actually.\n\u003e The theory was that local features concern direct peers, global features\n\u003e concern others (thus *must* be advertized by gossip).\n\u003e\n\u003e I *expected* local features to become ubiquitous over time, so by the\n\u003e time an implementation decided \"I don't even want to talk to nodes\n\u003e without feature X\" then most nodes would support feature X, so you could\n\u003e simply connect and you're probably OK.\n\u003e\n\u003e So the question becomes:\n\u003e\n\u003e 1. Do people want to pre-filter by local features?\n\u003e 2. If so, only some local features, or all of them?\n\u003e\n\u003e If only some, then we make those ones global features. If all, then we\n\u003e remove the local/global distinction altogether?\n\u003e\n\u003e Thanks,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "923e1e11e74080293313df367ef89da6a9ad0d64e20281e747ea8db7863efa232a6595f345ed2fae24214a29e75169c8a6bbfd6bf157771ff02d8e3e6e50dac6"
}