Asymmetric features

[t-bast]

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?

[lndhub-admin]

where is the line drawn on pure core LN protocol and LN application layer

for me pure core LN should not meddle with what application layer need implement anyway and can do so without extra cruft at pure core LN

or maybe i did not understand where the line is drawn / should be drawn ...

[t-bast]

@lndhub-admin I think this is completely orthogonal to the problem? The feature chosen is just here to illustrate my point.

[lndhub-admin]

wallet(LN) need be connected to the LN be able send / receive today

a flapping node is not a node = a wallet offline is not a node = wallets are not nodes.

having "pure core LN protocol" deal with that is to make a capable channel construct,
and not to have "pure core LN protocol" introduce out-of-LN-native-band services.

meaning LN application layer has to be able service the above scenario that some do today !
and could with a smart channel construct do without dependency OS notification services.

where do we think email would be today if i had to be present to receive when sender send !

using a construct like a add to the trampoline concept with the concepts of courier and post-box that would also have additional benefits when comes to privacy but in this specific use case allow for a deferred send / receive, allowing devices when inactive have presence as active by proxy and by channel Que be serviced or have service channel return request after set time-out (1D / 7D).

a wallet connects and open to a trampolineEX(tended) channel that forwards a pay_req and returns a preimage to wallet, in-turn if trampolineEX fails in settling pay_req at once it now have the amt in pay_req and retries settle until receives a preimage from receiver, alternatively time-out and balance back amt in pay_req to channel of initiating connected wallet.

that would have above case be in-band LN-Native or it is even possible today make same as a application out-of-band service deliver same functionality without dependencies OS notification services.

-- how do You do that ? I do not know !

but to have "pure core LN protocol" deal with application services out-of-band is <&*("/&%€"9>

[t-bast]

There are a lot of thing I don't understand in your answer.
But I think you're missing the point or talking about a completely different issue.

What I want to enable are asymmetrical features, where one node uses a service from another node without providing this service himself. It doesn't matter whether it's a wallet or a server node, this is something that may be beneficial in all cases. For example nodes on raspberry pis may want to leverage #881 which is an asymmetrical feature.

Please just forget about wallet or no wallet (or the specific example I gave) and just focus on the abstract proposal.

[lndhub-admin]

You say You do not understand and follow up with i missed the point ...

If You did not understand how can You say i missed the point ...

I might very well missed the point and Please both tell me what You did not understand and what i should understand.

A node can ask a node for service ? that node might have not have ? and if my node do not have a carwash my node should still be able use Your carwash ?

clear as mud . where is the dictionary for services and how would nodes find and interpret them M2M. :edit: N2N

[t-bast]

You're talking about wallet vs node and specific features and application layer vs core layer...all that has nothing to do with the proposal and is completely derailing the conversation.

Please forget about the concrete example that I mentioned and focus on the high-level proposal.

Some features are inherently asymmetrical (for example #881), where there is a "client" and a "provider".
There exists a communication protocol between these two nodes defined by a set of feature bits.
With the way feature bits work today, nodes have to support both the "client" and "provider" roles when they turn on the feature.
I'd like to see something more granular, where it's possible for a node to express "I support the client side of this protocol and I only want to connect to nodes that support the provider side of this protocol".

The goal of this issue is to discuss how that can be enabled.

[lndhub-admin]

In the issue You use a model and in a answer using that same model is then derailing the issue ?

[lndhub-admin]

"I support the client side of this protocol and I only want to connect to nodes that support the provider side of this protocol".

so graph could have feature announced and client then filters out ?

[t-bast]

so graph could have feature announced and client then filters out ?

That's not sufficient. You would of course do that for the first connection.
But imagine you're connected, everything goes well, and then at some point the provider turns off the feature.
When that happens you want to detect it automatically, to fail the connection early (and send a warning/error to let the provider know you need this feature).

One downside though if you stop connecting to peers who turn off the feature is that you don't have the opportunity to do a clean shutdown for your channels (because you need the init phase to be complete to shutdown channels). But that's true for every feature bit today, so it's not something new that this proposal would introduce.

[lndhub-admin]

well filter announcements - probe for active - then use or goto10

[t-bast]

No, that doesn't solve the following connections once you have a channel.

[lndhub-admin]

"But imagine you're connected, everything goes well, and then at some point the provider turns off the feature."

this is the nature of how YOU built the channels in LN . peers comes and goes - maybe peers should have backup proxys fallback redundancy where a fellow peer takes over when flapping ... impossible with today's undocumented protocol.

anyhow do not build in services outside of Your application that You need be up and stable = how come we should now build in services to a decentralized graph we know changes . in a model of Yours have a storage for channel backups is bad . since peer might dissapeer (<-- hint) . backup of channels a node operator has to make inhouse ! to secure place.

so what is use case that keysend as communication could not cover here ...

[t-bast]

After discussing it with @rustyrussell, he made me realize that we can actually interpret the existing spec in a way that makes that work (fortunately, present Rusty is at least as smart as past Rusty!). When we have a client and a provider side of a feature, we should create two related sets of feature bits:

• option_need_XXX
• option_provide_XXX

The client peer would set option_need_XXX and the provider peer would set option_provide_XXX, which lets them select peers from their node_announcement. The provider peer would provide the service only if the client has activated option_need_XXX and the client would only use the service if the provider has activated option_provide_XXX.

If clients want to ensure they only connect to providers who have activated that service, they should set option_need_XXX (mandatory). When receiving this features array, a peer would either:

• know that feature, in which case it checks if it has activated the provider side of it (option_provide_XXX) and otherwise drop the connection
• not know that feature, in which case it drops the connection

When the client receives a remote peer's features:

• if option_provide_XXX is activated, it proceeds with the connection
• otherwise it drops the connection

We simply need to clarify this common pattern of need_XXX / provide_XXX in Bolt 9, and this should work.
This has been included in #881.