📅 Original date posted:2022-07-01
📝 Original message:
Hi Joost,
As I've already stated every time this has been previously discussed, I
believe
this doesn't make any sense. The funds that are on the other side of the
channel belong to your peer, not you, so they're free to use it however they
want. If you're not happy with the way your peer is managing their fees,
then
don't open channels to them and let the network decide whether you're right
or
not.
Moreover, you shouldn't care at all. If all the funds are on your peer's
side,
this isn't your problem, you used up all the money that was yours. As long
as
the channel is open, this is free inbound liquidity for you, so you're even
benefiting from this.
If Alice could set fees for Bob's side of the channel, Alice could
arbitrarily
DoS Bob's payments by setting a high fee. This is just one example of the
many
ways this idea completely breaks the routing incentives.
Cheers,
Bastien
Le ven. 1 juil. 2022 à 13:10, Joost Jager <joost.jager at gmail.com> a écrit :
> Path-finding algorithms that are currently in use generally don’t support
>> negative fees. But in this case, the sum of inbound and outbound fees is
>> still positive and therefore not a problem. If routing nodes set their
>> policies accidentally or intentionally so that the sum of fees turns out
>> negative, senders can just round up to zero and find a path as normal.
>>
>
> Correction to this:
>
> The sum of inbound and outbound are not the fees set by one single routing
> node. When path-finding considers a candidate hop, this adds the outbound
> fee of the "from" node and the inbound fee of the "to" node. Because those
> nodes don't necessarily coordinate fees, it may happen more often that the
> fee goes negative. Rounding up to zero is still a quick fix and better than
> ignoring inbound fees completely.
> _______________________________________________
> 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/20220701/6b0313dc/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:06:31
in reply to nevent1q…8cwy
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:06:31Event JSON
{
"id": "ae04d6fe55f7665c3e25bf3bcdc57d717807f03cbfbd00e8f6d719308b69d42f",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315991,
"kind": 1,
"tags": [
[
"e",
"1a9ba01e2321d6681ec1af100da297280a7c9f0b5a592d574bfc7a5f8f13d6f1",
"",
"root"
],
[
"e",
"b512908b72e5f2d70439682b85e306aaf497dad1c7542f22ada36c1860fb909f",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2022-07-01\n📝 Original message:\nHi Joost,\n\nAs I've already stated every time this has been previously discussed, I\nbelieve\nthis doesn't make any sense. The funds that are on the other side of the\nchannel belong to your peer, not you, so they're free to use it however they\nwant. If you're not happy with the way your peer is managing their fees,\nthen\ndon't open channels to them and let the network decide whether you're right\nor\nnot.\n\nMoreover, you shouldn't care at all. If all the funds are on your peer's\nside,\nthis isn't your problem, you used up all the money that was yours. As long\nas\nthe channel is open, this is free inbound liquidity for you, so you're even\nbenefiting from this.\n\nIf Alice could set fees for Bob's side of the channel, Alice could\narbitrarily\nDoS Bob's payments by setting a high fee. This is just one example of the\nmany\nways this idea completely breaks the routing incentives.\n\nCheers,\nBastien\n\nLe ven. 1 juil. 2022 à 13:10, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e Path-finding algorithms that are currently in use generally don’t support\n\u003e\u003e negative fees. But in this case, the sum of inbound and outbound fees is\n\u003e\u003e still positive and therefore not a problem. If routing nodes set their\n\u003e\u003e policies accidentally or intentionally so that the sum of fees turns out\n\u003e\u003e negative, senders can just round up to zero and find a path as normal.\n\u003e\u003e\n\u003e\n\u003e Correction to this:\n\u003e\n\u003e The sum of inbound and outbound are not the fees set by one single routing\n\u003e node. When path-finding considers a candidate hop, this adds the outbound\n\u003e fee of the \"from\" node and the inbound fee of the \"to\" node. Because those\n\u003e nodes don't necessarily coordinate fees, it may happen more often that the\n\u003e fee goes negative. Rounding up to zero is still a quick fix and better than\n\u003e ignoring inbound fees completely.\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/20220701/6b0313dc/attachment.html\u003e",
"sig": "818531a9ffd50c94a1d26bd703577c566d4c79641b6ea9d75c853267561a912bbee48250e1653aacb1bedda282726825b64389613423854bc50fd775f8f03c70"
}