Joost Jager <[email protected]> writes: > On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell <[email protected]> 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. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
