<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell &lt;<a href="mailto:rusty@rustcorp.com.au" target="_blank">rusty@rustcorp.com.au</a>&gt; wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The decision was made to allow additional channel_update in the error<br>
reply:<br>
<br>
        DECISION: document that scid is not binding, allow extra<br>
        channel_updates in errors for “upselling”.<br></blockquote><div><br></div><div>Yes, I read this. What exactly is &quot;upselling&quot; 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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AFAICT this is a deeply weird case.  If another channel had capacity you<br>
would have just used it.  If another channel doesn&#39;t, sending a<br>
channel_update doesn&#39;t help.  And if there&#39;s a channel available at a<br>
higher feerate or longer timeout, it raises the question of why you&#39;re<br>
doing that rather than just taking the offer in front of you; that value<br>
clearly used to be acceptable, and now you risk them routing around you.<br></blockquote><div><br></div><div>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&#39;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&#39;t want this channel&#39;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.</div><div><br></div><div>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&#39;t need to bother with trying all other (equal policy) channels from that node to the next.</div><div> </div><div>Regards,</div><div>Joost</div></div></div>