đź“… Original date posted:2022-07-01
đź“ť Original message:
Hi Joost,
It was discussed in this issue:
https://github.com/lightning/bolts/issues/835
On the network, the traffic is not balanced. Some nodes tend to receive
more than they send, merchants for instance. For the lightning network to
be reliable, we need to incentivise people to open channels to such nodes,
or else there won't be enough liquidity available and payments will fail.
The current fee structure provides this incentive: You pay some onchain
fees and lock some funds and in exchange you will earn routing fees. My
concern is that your proposed change would break that incentive and make
the network less reliable.
Thomas
Le ven. 1 juil. 2022 Ă 14:02, Joost Jager <joost.jager at gmail.com> a Ă©crit :
> Hi Bastien,
>
> I vaguely remembered that the idea of inbound fees had been discussed
> before. Before writing my post, I scanned through old ML posts and bolts
> issues but couldn't find the discussion. Maybe it was part of a different
> but related email or a bolts pr?
>
> With regards to your objections, isn't it the case that it is always
> possible to DoS your peer by just rejecting any forward that comes in from
> them? Or indirectly affecting them negatively by setting high fees on all
> outbound channels? To me it seems that there is nothing to lose by adding
> inbound fees.
>
> My thinking is that if I accept an incoming htlc, my local balance
> increases on that incoming channel. My money gets locked up in a channel
> that may or may not be interesting to me. Wouldn't it be fair to be
> compensated for that?
>
> Any thoughts from routing node operators would be welcome too (or links to
> previous threads).
>
> Joost
>
> On Fri, Jul 1, 2022 at 1:19 PM Bastien TEINTURIER <bastien at acinq.fr>
> wrote:
>
>> 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
>>>
>> _______________________________________________
> 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/3c0f507d/attachment.html>;
Thomas HUET [ARCHIVE] /
npub1tc…pu5xp
2023-06-09 13:06:32
in reply to nevent1q…yquv
Author Public Key
npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xpPublished at
2023-06-09 13:06:32Event JSON
{
"id": "14cb7727d87f9ccc69d6b65bbdb365775ff529d885afbc9f15c9a62fe7b13d6c",
"pubkey": "5e1c3f4a2f0d0158103383abd1e3a582ab18c3ce6e02b50950b7836026135c9b",
"created_at": 1686315992,
"kind": 1,
"tags": [
[
"e",
"1a9ba01e2321d6681ec1af100da297280a7c9f0b5a592d574bfc7a5f8f13d6f1",
"",
"root"
],
[
"e",
"3bb170523b8bf885a3ea755dd4384976fcee6da64c87acc955c3ff34686eeea3",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2022-07-01\n📝 Original message:\nHi Joost,\n\nIt was discussed in this issue:\nhttps://github.com/lightning/bolts/issues/835\n\nOn the network, the traffic is not balanced. Some nodes tend to receive\nmore than they send, merchants for instance. For the lightning network to\nbe reliable, we need to incentivise people to open channels to such nodes,\nor else there won't be enough liquidity available and payments will fail.\nThe current fee structure provides this incentive: You pay some onchain\nfees and lock some funds and in exchange you will earn routing fees. My\nconcern is that your proposed change would break that incentive and make\nthe network less reliable.\n\nThomas\n\nLe ven. 1 juil. 2022 à 14:02, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e Hi Bastien,\n\u003e\n\u003e I vaguely remembered that the idea of inbound fees had been discussed\n\u003e before. Before writing my post, I scanned through old ML posts and bolts\n\u003e issues but couldn't find the discussion. Maybe it was part of a different\n\u003e but related email or a bolts pr?\n\u003e\n\u003e With regards to your objections, isn't it the case that it is always\n\u003e possible to DoS your peer by just rejecting any forward that comes in from\n\u003e them? Or indirectly affecting them negatively by setting high fees on all\n\u003e outbound channels? To me it seems that there is nothing to lose by adding\n\u003e inbound fees.\n\u003e\n\u003e My thinking is that if I accept an incoming htlc, my local balance\n\u003e increases on that incoming channel. My money gets locked up in a channel\n\u003e that may or may not be interesting to me. Wouldn't it be fair to be\n\u003e compensated for that?\n\u003e\n\u003e Any thoughts from routing node operators would be welcome too (or links to\n\u003e previous threads).\n\u003e\n\u003e Joost\n\u003e\n\u003e On Fri, Jul 1, 2022 at 1:19 PM Bastien TEINTURIER \u003cbastien at acinq.fr\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi Joost,\n\u003e\u003e\n\u003e\u003e As I've already stated every time this has been previously discussed, I\n\u003e\u003e believe\n\u003e\u003e this doesn't make any sense. The funds that are on the other side of the\n\u003e\u003e channel belong to your peer, not you, so they're free to use it however\n\u003e\u003e they\n\u003e\u003e want. If you're not happy with the way your peer is managing their fees,\n\u003e\u003e then\n\u003e\u003e don't open channels to them and let the network decide whether you're\n\u003e\u003e right or\n\u003e\u003e not.\n\u003e\u003e\n\u003e\u003e Moreover, you shouldn't care at all. If all the funds are on your peer's\n\u003e\u003e side,\n\u003e\u003e this isn't your problem, you used up all the money that was yours. As\n\u003e\u003e long as\n\u003e\u003e the channel is open, this is free inbound liquidity for you, so you're\n\u003e\u003e even\n\u003e\u003e benefiting from this.\n\u003e\u003e\n\u003e\u003e If Alice could set fees for Bob's side of the channel, Alice could\n\u003e\u003e arbitrarily\n\u003e\u003e DoS Bob's payments by setting a high fee. This is just one example of the\n\u003e\u003e many\n\u003e\u003e ways this idea completely breaks the routing incentives.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Bastien\n\u003e\u003e\n\u003e\u003e Le ven. 1 juil. 2022 à 13:10, Joost Jager \u003cjoost.jager at gmail.com\u003e a\n\u003e\u003e écrit :\n\u003e\u003e\n\u003e\u003e\u003e Path-finding algorithms that are currently in use generally don’t\n\u003e\u003e\u003e\u003e support negative fees. But in this case, the sum of inbound and outbound\n\u003e\u003e\u003e\u003e fees is still positive and therefore not a problem. If routing nodes set\n\u003e\u003e\u003e\u003e their policies accidentally or intentionally so that the sum of fees turns\n\u003e\u003e\u003e\u003e out negative, senders can just round up to zero and find a path as normal.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Correction to this:\n\u003e\u003e\u003e\n\u003e\u003e\u003e The sum of inbound and outbound are not the fees set by one single\n\u003e\u003e\u003e routing node. When path-finding considers a candidate hop, this adds the\n\u003e\u003e\u003e outbound fee of the \"from\" node and the inbound fee of the \"to\" node.\n\u003e\u003e\u003e Because those nodes don't necessarily coordinate fees, it may happen more\n\u003e\u003e\u003e often that the fee goes negative. Rounding up to zero is still a quick fix\n\u003e\u003e\u003e and better than ignoring inbound fees completely.\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\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/3c0f507d/attachment.html\u003e",
"sig": "87e9889a857380504c68563d42d6c0b2ab6e62c1f73afad1bff02d7b63f394123f328eab16fc9bac05d4d3a224b65a003f11be45494ae10cbf20084b46fee8d3"
}