More detailed definition when the dont_forward bit should be set

[ziggie1984]

Based on the PR which introduced the dont_forward bit, I think this bit was especially used to make implementations less error prune to not forward potential private information.

MAY create a channel_update to communicate the channel parameters to the channel peer, even though the channel has not yet been announced (i.e. the announce_channel bit was not set).

But I am wondering whether to set the bit in a ChannelUpdate msg for a public channel (not zeroconf) which originated lets say after 3 blocks (channel usable between peers) but still before 6 blocks (deadline where announcement sigs are exchanged)? I don't think we should set it in this case, but only set it either if its a private channel or a public zeroconf channel before the 6 conf target ?

If my assumption is true we should refine the spec in this case ?

[t-bast]

But I am wondering whether to set the bit in a ChannelUpdate msg for a public channel (not zeroconf) which originated lets say after 3 blocks (channel usable between peers) but still before 6 blocks (deadline where announcement sigs are exchanged)?

That sounds reasonable, we could indeed set dont_forward = true for the channel_update we send to our direct peer before the channel is announced. That channel_update is only useful for them to build their invoice routing hints, so making it explicit that they shouldn't forward it to anyone else sounds consistent.

I'd need to look at the code to see if this would have unwanted side effects though.

[ziggie1984]

I did not want to set it by default, because I thought maybe eclair nodes could lose the won advantage by switching this bit on for a short period of time and after 6 blocks we do not set it again. Looking forward to your findings, waiting until then before finalizing the LND PR.

[t-bast]

eclair nodes could lose the won advantage by switching this bit on for a short period of time and after 6 blocks we do not set it again.

I'm not sure what you mean here, can you detail?

[ziggie1984]

I thought when we set the dont_forward bit, eclair nodes treat these channels differently (saving some look ups in their tables because you have a lot of private channels). Now when we start to also set the bits for public channels during the time after initial confirmation (3 blocks default) and until the 6 confirmation is this still ok or will eclair have problems with the switching ?

[t-bast]

What made you think that? We don't do anything different than what the specification mandates. If you set the dont_forward bit, we won't forward the channel_update. If you don't set it, we will forward the channel_update. It should be as simple as that. I just had a look at our code, and this should work just fine.

[t-bast]

I'm not sure whether we've come up with something actionable on this issue?