Stefan Richter [ARCHIVE] on Nostr: 📅 Original date posted:2021-08-16 📝 Original message: Hi Zmn et al., >I propose ...
📅 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>;
📝 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>;