On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell <ru...@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? > AFAICT this is a deeply weird case. If another channel had capacity you > would have just used it. If another channel doesn't, sending a > channel_update doesn't help. And if there's a channel available at a > higher feerate or longer timeout, it raises the question of why you're > doing that rather than just taking the offer in front of you; that value > clearly used to be acceptable, and now you risk them routing around you. > Good point. If the value is acceptable, but that particular channel happens to have not enough balance, it is hard to explain why you wouldn't just accept. Maybe if you have a large capacity channel that you want to reserve for large amounts at a higher fee and you don't want this channel's balance to be used up by multiple non-strict forwarded small htlcs? This could also be realized by setting min_htlc, but then it can never be used for small htlcs. This admittedly is pretty specific. 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. Regards, Joost
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
