📅 Original date posted:2018-11-13
📝 Original message:
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.
Also, as ZmnSCPxj pointed out in his Wumbo-related post, just because
I support a feature doesn't mean that I want to apply it to any peer
that connects to my node. Since we can't advertise our whitelist or
whatever logic we use to enable a given feature for a particular node,
we can only be sure that a feature will be enabled by connecting to
the peer and seeing what's in the init message.
So how about just getting rid of the global/local distinction (I think
this can be done in a backward-compatible way), and use the following
instead:
- in the node_announcement message, have a node_features that
describes features my node supports/requires
- in the init message, have a connection_features that are set for
this particular connection.
Obviously node_features/connection_features are related and must
"match", in the sense that node_features constrains
connection_features, particularly if we use things like
option_anyone_can_wumbo (again referring to ZmnSCPxj's post).
Cheers,
Pierre
Pierre [ARCHIVE] /
npub1yz…y4pdt
2023-06-09 12:52:38
in reply to nevent1q…de8n
Author Public Key
npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdtPublished at
2023-06-09 12:52:38Event JSON
{
"id": "2b7216eb67b5444fb2682570a7033e064890e15525cae12e0047357a6a0ab8c0",
"pubkey": "208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff",
"created_at": 1686315158,
"kind": 1,
"tags": [
[
"e",
"7e19675ce2d9059ad28b8c6d674e5062c9c3e08808be8a20aebc7b4c921800e3",
"",
"root"
],
[
"e",
"db38bd41da3852ab1e6cdba92f114be3b4d69c8fed08bc3ee8fc3a8e16e1b82b",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-13\n📝 Original message:\nHi Rusty,\n\n\u003e The feature masks are split into local features (which only\n\u003e affect the protocol between these two nodes) and global features\n\u003e (which can affect HTLCs and are thus also advertised to other\n\u003e nodes).\n\nI don't think that definition makes a lot of sense. For example I\nprobably want to advertise the fact that my node supports\noption_data_loss_protect, which is a local feature. OTOH why would I\n*not* want to avertise a feature that I support? I struggle to see\nwhat is the point of making the distinction between local/global\nactually.\n\nAlso, as ZmnSCPxj pointed out in his Wumbo-related post, just because\nI support a feature doesn't mean that I want to apply it to any peer\nthat connects to my node. Since we can't advertise our whitelist or\nwhatever logic we use to enable a given feature for a particular node,\nwe can only be sure that a feature will be enabled by connecting to\nthe peer and seeing what's in the init message.\n\nSo how about just getting rid of the global/local distinction (I think\nthis can be done in a backward-compatible way), and use the following\ninstead:\n- in the node_announcement message, have a node_features that\ndescribes features my node supports/requires\n- in the init message, have a connection_features that are set for\nthis particular connection.\n\nObviously node_features/connection_features are related and must\n\"match\", in the sense that node_features constrains\nconnection_features, particularly if we use things like\noption_anyone_can_wumbo (again referring to ZmnSCPxj's post).\n\nCheers,\n\nPierre",
"sig": "c9e52786f9e940bc856ea04e4e1fe5407f26c69931dc65411c13fe1264b7fa27043081f1dc318bd4fb84474e9177d187d1c84663270a9a22ce4a6ca4c0701ccd"
}