📅 Original date posted:2021-08-16
📝 Original message:
Hi Zmn et al.,
>I propose that the algorithm be modified >as such, that is, it *ignore*
the fee scheme.
We actually started out thinking like this in the event we couldn't find a
proper way to handle fees, and the real world experiments we've done so far
have only involved probability costs, no fees at all.
However, I think it is non-trivial to deal with the many cases in which too
high fees could occur, and in the end the most systematic way of dealing
with them is actually including them in the cost function.
That said, I agree with Matt that more research needs to be done about the
effect of base fees on these computations. We do know they make the
problem hard in general, but we might find a way to deal with them
reasonably in practice.
I tend to agree with AJ, that I don't believe the base fee is economically
helpful, but I also think that the market will decide that rather than the
devs (though I would argue for default Zerobasefee in the implementations).
In my view, nobody is really earning any money with the base fee, so the
discussion is kind of artificial. On the other hand, I would estimate our
approach should lead to liquidity being priced correctly in the
proportional fee instead of the price being undercut by hobbyists as is the
case now. So in the long run I expect our routing method to make running a
well-stocked LN router much more profitable.
Cheers,
Stefan
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
schrieb am Mo., 16. Aug. 2021, 05:15:
> 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?)
>
>
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210816/f60fa4a3/attachment.html>;
Stefan Richter [ARCHIVE] /
npub19f…f4wf0
2023-06-09 13:03:28
in reply to nevent1q…yk5h
Author Public Key
npub19fnl48y9j4fk9w0a284mqvszq6fuppelqp2tcxf0s37l95avdtussf4wf0Published at
2023-06-09 13:03:28Event JSON
{
"id": "875c30ff2cf688a6b3dc9d3877e94c93cdef184356c17afea5add63e89686ec7",
"pubkey": "2a67fa9c85955362b9fd51ebb032020693c0873f0054bc192f847df2d3ac6af9",
"created_at": 1686315808,
"kind": 1,
"tags": [
[
"e",
"9c2d9ebc7daf40e6a14ddb62eed3add34417e7bccd1a15aa0b16d2df92878dde",
"",
"root"
],
[
"e",
"d4ca85b6856245ac5c6bb4d8a481beb76e67fb5a3e5ed7a031389a816b37484a",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-08-16\n📝 Original message:\nHi Zmn et al.,\n\n\u003eI propose that the algorithm be modified \u003eas such, that is, it *ignore*\nthe fee scheme.\n\nWe actually started out thinking like this in the event we couldn't find a\nproper way to handle fees, and the real world experiments we've done so far\nhave only involved probability costs, no fees at all.\n\nHowever, I think it is non-trivial to deal with the many cases in which too\nhigh fees could occur, and in the end the most systematic way of dealing\nwith them is actually including them in the cost function.\n\nThat said, I agree with Matt that more research needs to be done about the\neffect of base fees on these computations. We do know they make the\nproblem hard in general, but we might find a way to deal with them\nreasonably in practice.\n\nI tend to agree with AJ, that I don't believe the base fee is economically\nhelpful, but I also think that the market will decide that rather than the\ndevs (though I would argue for default Zerobasefee in the implementations).\n\nIn my view, nobody is really earning any money with the base fee, so the\ndiscussion is kind of artificial. On the other hand, I would estimate our\napproach should lead to liquidity being priced correctly in the\nproportional fee instead of the price being undercut by hobbyists as is the\ncase now. So in the long run I expect our routing method to make running a\nwell-stocked LN router much more profitable.\n\nCheers,\n Stefan\n\nZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e\nschrieb am Mo., 16. Aug. 2021, 05:15:\n\n\u003e Good morning matt and aj,\n\u003e\n\u003e Let me cut in here.\n\u003e\n\u003e From my reading of the actual paper --- which could be a massive\n\u003e misunderstanding, as I can barely understand half the notation, I am more a\n\u003e dabbler in software engineering than a mathist --- it seems to me that it\n\u003e would be possible to replace the cost function in the planning algorithm\n\u003e with *only* the negative-log-probability, which I think is the key point of\n\u003e the paper.\n\u003e\n\u003e That is, the algorithm can be run in a mode where it *ignores* whatever\n\u003e fee scheme forwarding nodes desire.\n\u003e (@rene: correct me if I am wrong?)\n\u003e\n\u003e\n\u003e However, the algorithm then gets an extra step after getting a payment\n\u003e plan (i.e. how to route multiple sub-payments).\n\u003e It looks over the payment plan and if the fees involved are beyond some\n\u003e user-defined limit (with, say, a default of 0.5% of the total amount, as\n\u003e per the C-Lightning `pay` default), to look at the highest-fee channels in\n\u003e the payment plan.\n\u003e Then, it can rerun the flow algorithm, telling it to *disallow* the\n\u003e highest-fee channels identified if the total fees exceed the fee budget.\n\u003e\n\u003e It seems to me that this modification of the algorithm may be sufficient\n\u003e to be resilient against any and all future fee scheme we may decide for\n\u003e Lightning.\n\u003e\n\u003e This still achieves \"optimality\" in the sense of the paper, in a way\n\u003e similar to what is suggested in the paper.\n\u003e The paper suggests to basically ignore gossiped channels with non-zero\n\u003e basefee.\n\u003e The approach I suggest allows us to *start* without ignoring non-zero\n\u003e basefee, but to slowly degrade our view of the network by disallowing\n\u003e high-fee (whether high basefee or high propfee) channels.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210816/f60fa4a3/attachment.html\u003e",
"sig": "ee2a04ec9eeb7932392208127a206ac763f3d332c20931ec153e8f084d5fcac62df8bddf6df6a64d8a12f2f56499c391a21fe410b10b9babcaf96518d6125925"
}