📅 Original date posted:2021-07-08
📝 Original message:
Good morning list,
I've been mulling over some limitations of our feature bits mechanism and
I'm interested in your ideas and comments.
Our feature bits mechanism works well for symmetric features (where both
peers play the same role) but not so well for asymmetric features (where
there is a client and a service provider). Here is a hypothetical example to
illustrate that. Any similarity to existing wallet features is entirely
coincidental.
Alice has a mobile lightning wallet that can be woken up via push
notifications.
Bob runs a lightning node that can send push notifications to mobile
wallets to
wake them up on important events (e.g. incoming htlcs).
We can't use a single feature bit to model that, because what Alice supports
is actually "I can be woken up via push notifications", but she can't send
push
notifications to other nodes (and similarly, Bob only supports waking up
other
nodes, not receiving push notifications).
So we must use two feature bits: `wake_me_up_plz` and `i_say_wake_up`.
Alice activates `wake_me_up_plz`, Bob activates `i_say_wake_up` and it's
now clear what part of the protocol each node can handle.
But how does Alice require her peers to support `i_say_wake_up`?
She can't turn on the feature with the mandatory bit because then her peers
would be confused and think she can wake up other devices.
I see two potential solutions:
1. Re-purpose the meaning of `optional` and `mandatory` bits for
asymmetric feature: the odd bit would mean "I support this feature"
and the even bit would mean "I require my peer to support this feature"
2. Add a requirement to send a warning and disconnect when a client
connects to a provider that hasn't activated the provider-side feature
Thoughts?
Cheers,
Bastien
Note: I opened an issue for that for those who prefer github:
https://github.com/lightningnetwork/lightning-rfc/issues/885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210708/d523308b/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:03:04
in reply to nevent1q…tj3x
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:03:04Event JSON
{
"id": "49a2954d6ad7b3c6fa091c79bf19f68f33892eb5fc79d6172532e53181c15d1f",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315784,
"kind": 1,
"tags": [
[
"e",
"1fa6e64ee737ed78f8a439581d3942e61ba0c7c0bae101a16673f65f65454efd",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-07-08\n📝 Original message:\nGood morning list,\n\nI've been mulling over some limitations of our feature bits mechanism and\nI'm interested in your ideas and comments.\n\nOur feature bits mechanism works well for symmetric features (where both\npeers play the same role) but not so well for asymmetric features (where\nthere is a client and a service provider). Here is a hypothetical example to\nillustrate that. Any similarity to existing wallet features is entirely\ncoincidental.\n\nAlice has a mobile lightning wallet that can be woken up via push\nnotifications.\nBob runs a lightning node that can send push notifications to mobile\nwallets to\nwake them up on important events (e.g. incoming htlcs).\n\nWe can't use a single feature bit to model that, because what Alice supports\nis actually \"I can be woken up via push notifications\", but she can't send\npush\nnotifications to other nodes (and similarly, Bob only supports waking up\nother\nnodes, not receiving push notifications).\n\nSo we must use two feature bits: `wake_me_up_plz` and `i_say_wake_up`.\nAlice activates `wake_me_up_plz`, Bob activates `i_say_wake_up` and it's\nnow clear what part of the protocol each node can handle.\n\nBut how does Alice require her peers to support `i_say_wake_up`?\nShe can't turn on the feature with the mandatory bit because then her peers\nwould be confused and think she can wake up other devices.\n\nI see two potential solutions:\n\n 1. Re-purpose the meaning of `optional` and `mandatory` bits for\n asymmetric feature: the odd bit would mean \"I support this feature\"\n and the even bit would mean \"I require my peer to support this feature\"\n 2. Add a requirement to send a warning and disconnect when a client\n connects to a provider that hasn't activated the provider-side feature\n\nThoughts?\n\nCheers,\nBastien\n\nNote: I opened an issue for that for those who prefer github:\nhttps://github.com/lightningnetwork/lightning-rfc/issues/885\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210708/d523308b/attachment.html\u003e",
"sig": "04ef0dff2a077109c3b0b7525d3a96bd014bf15e10b0c6acd0ff733d309f8d7ec28f140d390f0e36376a4a103465f5686b983e0fa9400f9d201cb764835215de"
}