ZmnSCPxj [ARCHIVE] on Nostr: š
Original date posted:2021-08-16 š Original message: Good morning matt and aj, ...
š
Original date posted:2021-08-16
š Original message:
Good morning matt and aj,
Let me cut in here.
>From my reading of the actual paper --- which could be a massive misunderstanding, as I can barely understand half the notation, I am more a dabbler in software engineering than a mathist --- it seems to me that it would be possible to replace the cost function in the planning algorithm with *only* the negative-log-probability, which I think is the key point of the paper.
That is, the algorithm can be run in a mode where it *ignores* whatever fee scheme forwarding nodes desire.
(@rene: correct me if I am wrong?)
I propose that the algorithm be modified as such, that is, it *ignore* the fee scheme.
However, the algorithm then gets an extra step after getting a payment plan (i.e. how to route multiple sub-payments).
It looks over the payment plan and if the fees involved are beyond some user-defined limit (with, say, a default of 0.5% of the total amount, as per the C-Lightning `pay` default), to look at the highest-fee channels in the payment plan.
Then, it can rerun the flow algorithm, telling it to *disallow* the highest-fee channels identified if the total fees exceed the fee budget.
It seems to me that this modification of the algorithm may be sufficient to be resilient against any and all future fee scheme we may decide for Lightning.
This still achieves "optimality" in the sense of the paper, in a way similar to what is suggested in the paper.
The paper suggests to basically ignore gossiped channels with non-zero basefee.
The approach I suggest allows us to *start* without ignoring non-zero basefee, but to slowly degrade our view of the network by disallowing high-fee (whether high basefee or high propfee) channels.
Regards,
ZmnSCPxj
Published at
2023-06-09 12:40:59Event JSON
{
"id": "deb4d384d9a2f42f712763f74ee662f7a56c5cb786faa65a64748886814917b5",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686314459,
"kind": 1,
"tags": [
[
"e",
"9d3801d66d3239d18d7b986ecb31f0f1d7b54c421aae753d10192ad5353e49a0",
"",
"root"
],
[
"e",
"c5eec6756fb645a7fbd659970a48020db36f59e4093f0e2473046c816b01959b",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "š
Original date posted:2021-08-16\nš Original message:\nGood morning matt and aj,\n\nLet me cut in here.\n\n\u003eFrom my reading of the actual paper --- which could be a massive misunderstanding, as I can barely understand half the notation, I am more a dabbler in software engineering than a mathist --- it seems to me that it would be possible to replace the cost function in the planning algorithm with *only* the negative-log-probability, which I think is the key point of the paper.\n\nThat is, the algorithm can be run in a mode where it *ignores* whatever fee scheme forwarding nodes desire.\n(@rene: correct me if I am wrong?)\n\nI propose that the algorithm be modified as such, that is, it *ignore* the fee scheme.\n\nHowever, the algorithm then gets an extra step after getting a payment plan (i.e. how to route multiple sub-payments).\nIt looks over the payment plan and if the fees involved are beyond some user-defined limit (with, say, a default of 0.5% of the total amount, as per the C-Lightning `pay` default), to look at the highest-fee channels in the payment plan.\nThen, it can rerun the flow algorithm, telling it to *disallow* the highest-fee channels identified if the total fees exceed the fee budget.\n\nIt seems to me that this modification of the algorithm may be sufficient to be resilient against any and all future fee scheme we may decide for Lightning.\n\nThis still achieves \"optimality\" in the sense of the paper, in a way similar to what is suggested in the paper.\nThe paper suggests to basically ignore gossiped channels with non-zero basefee.\nThe approach I suggest allows us to *start* without ignoring non-zero basefee, but to slowly degrade our view of the network by disallowing high-fee (whether high basefee or high propfee) channels.\n\nRegards,\nZmnSCPxj",
"sig": "e8db31f39ba77e533c14b59b3749fc5f2c7686d9471dc84d182562d5885b0f0b2a651fb76b9c6662562d94e53add522a067ff9751113bbe010a8af20655edbcc"
}