📅 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
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:52:44
in reply to nevent1q…9vys
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:52:44Event JSON
{
"id": "25f273dfb6e4d86f9125ba02cab3bf09cea02c3979f728a83d4ca6600fa92708",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686315164,
"kind": 1,
"tags": [
[
"e",
"809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478",
"",
"root"
],
[
"e",
"46c007ff133a52b3d6f646a12e701e05d7c41e49f86e8a971f19767bdfd52802",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-16\n📝 Original message:\nOn Thu, Nov 15, 2018 at 11:54:22PM +0000, ZmnSCPxj via Lightning-dev wrote:\n\u003e The improvement is in a reduction in `fee_base_msat` in the C-\u003eD path.\n\nI think reliability (and simplicity!) are the biggest things to improve\nin lightning atm. Having the flag just be incuded in invoices and not\nneed to be gossiped seems simpler to me; and I think endpoint-only\nmerging is better for reliability too. Eg, if you find candidate routes:\n\n A -\u003e B -\u003e M -- actual directed capacity $6\n A -\u003e C -\u003e M -- actual directed capacity $5.50\n M -\u003e E -\u003e F -- actual directed capacity $6\n A -\u003e X -\u003e F -- actual directed capacity $7\n\nand want to send $9 form A to F, you might start by trying to send\n$5 via B and $4 via C.\n\nWith endpoint-only merging you'd do:\n\n $5 via A,B,M,E,F -- partial success\n $4 via A,C,M,E -- failure\n $4 via A,X,F -- payment completion\n\nwhereas with in-route merging, you'd do:\n\n $5 via A,B,M -- held\n $4 via A,C,M -- to be continued\n $9 via M,E -- both partial payments fail\n\nwhich seems a fair bit harder to incrementally recover from.\n\n\u003e Granted, current `fee_base_msat` across the network is very low currently.\n\u003e So I do not object to restricting merge points to ultimate payees.\n\u003e If fees rise later, we can revisit this.\n\nSo, while we already agree on the approach to take, I think the above\nprovides an additional rationale :)\n\nCheers,\naj",
"sig": "b74c7b17e26982211b1eded89fa708cb0d966a8ee7068f2c53ef5c26a6105fa7e2bc53a0fa4df08c32b01aa310856f21c4438541b210d4ae6178ea05322d93f0"
}