Why Nostr? What is Njump?
2023-06-09 12:40:59
in reply to

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
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l