<div>Good morning Rene,<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>Hey List,&nbsp;<br></div><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.<br></div><div><br></div><div>## Verifying:&nbsp;<br></div><div>1.) I understand the receiving node signals support for Base AMP by setting a feature bit in the BOLT11 String<br></div></div></blockquote><div><br></div><div>Correct.<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><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`.<br></div></div></blockquote><div><br></div><div>The bit is not a "feature bit" specifically, as it is not a feature --- instead, it is a mode of operation or option.<br></div><div>Perhaps semantics only, however.<br></div><div>Otherwise, correct.<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>## Clarifying:<br></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.<br></div></div></blockquote><div><br></div><div>MUST NOT, since an incomplete payment can only be signaled for final nodes.<br></div><div>I can explicitly use MUST NOT here I suppose.<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>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)<br></div></div></blockquote><div><br></div><div>It would be easily doable to have the rest of the onion be the same for each incoming partial path.<br></div><div>An intermediate hop just needs to store one onion, and compare the HMAC of a second or third incoming onion to differentiate between different forward-merges.<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div>## Proposing:&nbsp;<br></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:&nbsp;<br></div><div><br></div><div>def pay_base_amp(amount):<br></div><div>&nbsp; &nbsp;success = False<br></div><div>&nbsp; &nbsp;for route in get_available_routes():<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp;success = send_via_route(route, amount)<br></div><div>&nbsp; &nbsp; if not success:<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp;pay_base_amp(amount/2 + 1) # the&nbsp;+1 is to mitigate rounding errors. there could be other ways to do so.<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp;pay_base_amp(amount/2 + 1)<br></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<br></div></div></blockquote><div><br></div><div>The above naive scheme will not work in the general case.<br></div><div><br></div><div>See: <a href="https://lists.ozlabs.org/pipermail/c-lightning/2018-November/000084.html">https://lists.ozlabs.org/pipermail/c-lightning/2018-November/000084.html</a><br></div><div>It will not work well with the proposed `test_amp_unequal`, `test_amp_3way`. and `test_amp_5way` tests, at least until the amount has been split into tiny parts, possibly with fees becoming an issue (particularly `fee_base_msat`) due to having been split into many tiny parts.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>