<div dir="ltr">Hey List, <div><br></div><div>as this base AMP proposal seems pretty small I just started to write this up to make a PR for BOLT04 and BOLT11. While doing my write up I realize that there are smaller things that I would want to verify / double check and propose with you.</div><div><br></div><div>## Verifying: </div><div>1.) I understand the receiving node signals support for Base AMP by setting a feature bit in the BOLT11 String</div><div>2.) The sending node signals a multipath payment by setting a feature bit and by using the same `amount to forward` value in the last hop of the onion for all paths which will also be bigger that the incoming htlcs whose sum has to be at least the size of `amount_to_forward`.</div><div><br></div><div>## Clarifying:</div><div>3.) Senders MUST NOT (SHOULD NOT?) create paths which would have to be merged by intermediary nodes (as we don't know - and have no means of querying - if they support the format of the adepted onion packages for partial paths. Also it even seems impossible since the rest of the path for at least one partial path could not be stored in the onion / forwarded onions can't be seen)</div><div><br></div><div>## Proposing: </div><div>Should we specify an algorithm for executing a multipath payment for the sending node or should this be left to the implementation. An obvious Idea for an algorithm would be a divide and conquer scheme which should be obvious with the following python style pseudo code: </div><div><br></div><div>def pay_base_amp(amount):</div><div> success = False</div><div> for route in get_available_routes():</div><div> success = send_via_route(route, amount)</div><div> if not success:</div><div> pay_base_amp(amount/2 + 1) # the +1 is to mitigate rounding errors. there could be other ways to do so.</div><div> pay_base_amp(amount/2 + 1)</div><div><br></div><div>Even if we leave the exact AMP execution to the sender we could still suggest this divide and conquer scheme in BOLT 04</div><div><br></div><div>Another idea I had (which is probably a bad one as it allows for probing of channel balances) would be to allow nodes on a partial path to send back some hints of how much additional capacity they can forward if they see that the partial payment feature bit is set (this would require to set this feature bit in every onion) Also if we want to make use of this information every node would have to support base amp. So I guess this idea is bad for several reasons. Still we could have a MAY rule out of it?</div><div><br></div><div>best Rene </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 4:45 PM Anthony Towns <<a href="mailto:aj@erisian.com.au">aj@erisian.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 15, 2018 at 11:54:22PM +0000, ZmnSCPxj via Lightning-dev wrote:<br>
> The improvement is in a reduction in `fee_base_msat` in the C->D path.<br>
<br>
I think reliability (and simplicity!) are the biggest things to improve<br>
in lightning atm. Having the flag just be incuded in invoices and not<br>
need to be gossiped seems simpler to me; and I think endpoint-only<br>
merging is better for reliability too. Eg, if you find candidate routes:<br>
<br>
A -> B -> M -- actual directed capacity $6<br>
A -> C -> M -- actual directed capacity $5.50<br>
M -> E -> F -- actual directed capacity $6<br>
A -> X -> F -- actual directed capacity $7<br>
<br>
and want to send $9 form A to F, you might start by trying to send<br>
$5 via B and $4 via C.<br>
<br>
With endpoint-only merging you'd do:<br>
<br>
$5 via A,B,M,E,F -- partial success<br>
$4 via A,C,M,E -- failure<br>
$4 via A,X,F -- payment completion<br>
<br>
whereas with in-route merging, you'd do:<br>
<br>
$5 via A,B,M -- held<br>
$4 via A,C,M -- to be continued<br>
$9 via M,E -- both partial payments fail<br>
<br>
which seems a fair bit harder to incrementally recover from.<br>
<br>
> Granted, current `fee_base_msat` across the network is very low currently.<br>
> So I do not object to restricting merge points to ultimate payees.<br>
> If fees rise later, we can revisit this.<br>
<br>
So, while we already agree on the approach to take, I think the above<br>
provides an additional rationale :)<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><a href="https://www.rene-pickhardt.de" target="_blank">https://www.rene-pickhardt.de</a></div><div><br></div><div>Skype: rene.pickhardt <br></div><div><br></div><div>mobile: +49 (0)176 5762 3618 </div></div></div></div></div></div></div>