From rusty at rustcorp.com.au  Tue Nov 20 00:09:16 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 20 Nov 2018 10:39:16 +1030
Subject: [Lightning-dev] Forwarding hints in channel update messages
In-Reply-To: <CAJBJmV-X_fpiM_poYcenvx6i2T59ne0xZLzixco5pwvMw+jjPQ@mail.gmail.com>
References: <CAJBJmV-E-XaHnC8ET+sxrsM0Fs8EwzmCZNszYszTCh+B4rQU4w@mail.gmail.com>
	<87y39vflkh.fsf@rustcorp.com.au>
	<CAJBJmV-X_fpiM_poYcenvx6i2T59ne0xZLzixco5pwvMw+jjPQ@mail.gmail.com>
Message-ID: <87tvkcd2z7.fsf@rustcorp.com.au>

Joost Jager <joost.jager at gmail.com> writes:
> On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> The decision was made to allow additional channel_update in the error
>> reply:
>>
>>         DECISION: document that scid is not binding, allow extra
>>         channel_updates in errors for ?upselling?.
>>
>
> Yes, I read this. What exactly is "upselling" in this context and how were
> extra channel_updates in errors intended to be used for this? Is it useful
> for non-strict forwarding nodes?

Every node should be non-strict, in the sense that we could never detect
it anyway.  This change is just to explicitly document that.  scid is used
as a cheap way of specifying next hop, and gives an additional hint as
to why we chose the feerate we did, and is not binding.

The extra channel_updates allow a node to indicate that there are
alternate channels which could be used instead (presumably at a higher
feerate).

> Maybe the forwarding hint that could make more of a difference is just the
> information that non-strict forwarding was actually applied. Communicate
> this as a node property via a global feature bit. If the sender receives a
> TemporaryChannelFailure from a non-strict forwarding node, it doesn't need
> to bother with trying all other (equal policy) channels from that node to
> the next.

That's an internal matter which shouldn't leak, AFAICT.

Cheers,
Rusty.