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
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
