<div>Good morning list,<br></div><div><br></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div dir="ltr"><div>I realized the other day that the wumbo bit should also likely encompass wumbo<br></div><div>payments. What good is a wumbo channel that doesn't also allow wumbo payments?<br></div><div>Naturally if the bit is signalled globally, then this should also signal the<br></div><div>willingness of the node to forward larger payments up to their max_htlc limit<br></div><div>within the channel_update for that link.<br></div></div></blockquote><div><br></div><div>This certainly is true, but, much of the wumbo payments would be implemented by AMP.<br></div><div><br></div><div>If there is no direct path of wumborama nodes from payer to payee, then wumbo payments will have to be done by AMP.<br></div><div>It would be nice if we could have AMP merge into intermediate nodes instead of always at the destination --- that way, only the suffix of the path needs to be wumborama.<br></div><div>Certainly this would be less of an issue as more nodes signal wumborama; we know from previous user behavior that they will be #reckless and enable wumborama as soon as it is implemented.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div dir="ltr"><div>On a similar note, I was reviewing the newer-ish section of the spec concerning<br></div><div>the optional max_htlc value. I noticed an inconsistency: it states the value<br></div><div>should be below the max capacity of the channel, but makes no reference to the<br></div><div>current (pre wumbo) _max HTLC limit_. As a result, as it reads now, one may<br></div><div>interpret signalling of the optional field as eligibility to route wumbo<br></div><div>payments in a pre-wumbo channel world.<br></div><div><br></div><div>-- Laolu<br></div><div><br></div></div><div><br></div><div class="gmail_quote"><div dir="ltr">On Tue, Nov 13, 2018 at 3:34 PM Rusty Russell &lt;<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>ZmnSCPxj via Lightning-dev &lt;<a href="mailto:lightning-dev@lists.linuxfoundation.org" target="_blank">lightning-dev@lists.linuxfoundation.org</a>&gt; writes:<br></div><div> &gt; Thus, I propose:<br></div><div> &gt;<br></div><div> &gt; * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the node is willing to wumbo with its counterparty in the connection.<br></div><div> &gt; * The global feature bit `option_anyone_can_wumbo`, which indicates that the node is willing to wumbo with any node.<br></div><div> <br></div><div> I think we need to name `option_anyone_can_wumbo` to `option_wumborama`?<br></div><div> <br></div><div> Otherwise, this looks excellent.<br></div><div> <br></div><div> Thanks,<br></div><div> Rusty.<br></div><div> _______________________________________________<br></div><div> Lightning-dev mailing list<br></div><div> <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br></div><div> <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br></div></blockquote></div></blockquote><div><br></div>