config: mark channels as disabled for routing when rejecthtlc=1

[alexbosworth]

Background

When setting the configuration option to disallow all routing on all channels with rejecthtlc=1, it would be friendly to the network and to peers to pre-indicate to them that their attempts to route through the channel will be rejected.

This could help prevent slow pathfinding scenarios and help with future graph sync optimizations where disabled edges are de-prioritized for on-boarding or catchup graph sync.

The disabled flag should not preclude:

• Receiving over channels (disabled is marked only on the outgoing edge)
• Direct sending over channels (the internal pathfinding should ignore the public graph marker)

Your environment

• LND v0.11.1-beta

[ellemouton]

question here on the expected behaviour:

So if we startup with rejecthtlc=1 - we will go ahead and disable all the channels. But then if we after that startup with rejecthtlc=0 - do we need to remember which channels we went and disabled due to the previous rejecthtlc=1 and then go auto-reenable those? or is it fine to leave those disabled and let the user manually go re-enable them?

I guess option 1 would be best especially for the case of lots of channels - but it would require some persistence & special-case logic which is why I ask

[alexbosworth]

I think you'd want to reenable channels if the rejecthtlc was turned off

[lightninglabs-deploy]

Consolidating related issue here. The following has been closed as a duplicate:

• htlcswitch: enforce channel disable at the link level  #5088 — Implementation-level issue by roasbeef: when a channel is disabled via ChannelUpdate with the disable bit, it's currently advisory only — SendToRoute can still route through it. Fix: where we check the --rejecthtlc flag, also check the channel disabled status and return FailChannelDisabled error with an updated ChannelUpdate. Steps to completion are defined in that issue.