Sending incorrect onion error for "peer offline"

[TheBlueMatt]

In discussion it came up that lnd currently sends an onion error with the PERM bit set when the peer is offline. This actually informs the sender that they should fully remove the channel from the graph and not attempt to route back over the channel again, losing out on routing revenue. Instead, temporary_channel_failure is intended to cover this, per the BOLT spec.

[Roasbeef]

Our behavior is based on this fragment:

if the receiving peer specified by the onion is NOT known: return an unknown_next_peer error.

So IMO the wording can be tightened up here, as temporary_channel_failure is expressed sort of as a catch all ("an otherwise unspecified"), so perhaps we need to define a stricter ordering here w.r.t interpretation and also enumerate all the cases that temporary_channel_failure should actually be sent.

[TheBlueMatt]

Agreed the BOLTs should be tightened, but the peer is clearly known, even if they're offline. The other point is the definition of PERM is much more clear, and unknown_next_peer has the PERM bit set.

[TheBlueMatt]

FWIW, the use of temporary_channel_failure as a bit of a catch-all is also a deliberate decision to provide a more general protection/strategic ambiguity as to balance probing, so there's very good reason for it to be very broad.

[alexbosworth]

Since LND will automatically send out a disabled update for an offline peer, maybe the error should be channel disabled

I think this is already done by another implementation

[TheBlueMatt]

Hmm, good point, both would be valid here, I assume, in either case you'd include a channel_udpate with the disabled bit set, which ultimately the sender should treat the same - they mostly look at the channel_update and apply it to their graph, less look at the specific issue.