Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-16 📝 Original message: On Thu, Nov 15, 2018 at ...

📅 Original date posted:2018-11-16
📝 Original message:
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