On Thu, Nov 15, 2018 at 11:54:22PM +0000, ZmnSCPxj via Lightning-dev wrote: > The improvement is in a reduction in `fee_base_msat` in the C->D path.
I think reliability (and simplicity!) are the biggest things to improve in lightning atm. Having the flag just be incuded in invoices and not need to be gossiped seems simpler to me; and I think endpoint-only merging is better for reliability too. Eg, if you find candidate routes: A -> B -> M -- actual directed capacity $6 A -> C -> M -- actual directed capacity $5.50 M -> E -> F -- actual directed capacity $6 A -> X -> F -- actual directed capacity $7 and want to send $9 form A to F, you might start by trying to send $5 via B and $4 via C. With endpoint-only merging you'd do: $5 via A,B,M,E,F -- partial success $4 via A,C,M,E -- failure $4 via A,X,F -- payment completion whereas with in-route merging, you'd do: $5 via A,B,M -- held $4 via A,C,M -- to be continued $9 via M,E -- both partial payments fail which seems a fair bit harder to incrementally recover from. > Granted, current `fee_base_msat` across the network is very low currently. > So I do not object to restricting merge points to ultimate payees. > If fees rise later, we can revisit this. So, while we already agree on the approach to take, I think the above provides an additional rationale :) Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
