📅 Original date posted:2020-10-13
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).
> fee_base is in there to compensate for the usage of an htlc slot, which is
> a scarce resource too.
...
>
> In both cases the sender needs to trust its peer to not steal the payment
> and/or artificially delay the forwarding to inflate the hold fee. I think
> that is acceptable given that there is a trust relation between peers
> already anyway.
>
> A crucial thing is that these hold fees don't need to be symmetric. A new
> node for example that opens a channel to a well-known, established routing
> node will be forced to pay a hold fee, but won't see any traffic coming in
> anymore if it announces a hold fee itself. Nodes will need to build a
> reputation before they're able to command hold fees. Similarly, routing
> nodes that have a strong relation may decide to not charge hold fees to
> each other at all.
I can still establish channels to various low-reputation nodes, and then
use them to grief a high-reputation node. Not only do I get to jam up
the high-reputation channels, as a bonus I get the low-reputation nodes
to pay for it!
Operators of high reputation nodes can even make this profitable; doubly
so, since they eliminate the chance of any of those low-reputation nodes
every getting to be high reputation (and thus competing).
AFAICT any scheme which penalizes the direct peer creates a bias against
forwarding unknown payments, thus is deanonymizing.
> I'd also like to encourage everyone to prioritize this spam/jam issue and
> dedicate more time to solving it. Obviously there is a lot more to do in
> Lightning, but I am not sure if we can afford to wait for the real
> adversaries to show up on this one.
Agreed. It's a classic "it's not actually on fire *right now*" problem,
so it does keep getting pushed back.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 13:01:10
in reply to nevent1q…qf00
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 13:01:10Event JSON
{
"id": "ac09b4f5c096beac1381e79c8cfb11c487af5edc4cfd2cb53a3167c3c103299c",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315670,
"kind": 1,
"tags": [
[
"e",
"2e5ffd65d86c5774dbb4381933898049e781bd6e8719e31c24e98ee704e67d6e",
"",
"root"
],
[
"e",
"a35867c0d64eb2cbd2e0df85a3a8bdd920300c210c8a84912b1ed0e2a7c68024",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-10-13\n📝 Original message:\nJoost Jager \u003cjoost.jager at gmail.com\u003e writes:\n\u003e This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).\n\u003e fee_base is in there to compensate for the usage of an htlc slot, which is\n\u003e a scarce resource too.\n\n...\n\u003e \n\u003e In both cases the sender needs to trust its peer to not steal the payment\n\u003e and/or artificially delay the forwarding to inflate the hold fee. I think\n\u003e that is acceptable given that there is a trust relation between peers\n\u003e already anyway.\n\u003e\n\u003e A crucial thing is that these hold fees don't need to be symmetric. A new\n\u003e node for example that opens a channel to a well-known, established routing\n\u003e node will be forced to pay a hold fee, but won't see any traffic coming in\n\u003e anymore if it announces a hold fee itself. Nodes will need to build a\n\u003e reputation before they're able to command hold fees. Similarly, routing\n\u003e nodes that have a strong relation may decide to not charge hold fees to\n\u003e each other at all.\n\nI can still establish channels to various low-reputation nodes, and then\nuse them to grief a high-reputation node. Not only do I get to jam up\nthe high-reputation channels, as a bonus I get the low-reputation nodes\nto pay for it!\n\nOperators of high reputation nodes can even make this profitable; doubly\nso, since they eliminate the chance of any of those low-reputation nodes\nevery getting to be high reputation (and thus competing).\n\nAFAICT any scheme which penalizes the direct peer creates a bias against\nforwarding unknown payments, thus is deanonymizing.\n\n\u003e I'd also like to encourage everyone to prioritize this spam/jam issue and\n\u003e dedicate more time to solving it. Obviously there is a lot more to do in\n\u003e Lightning, but I am not sure if we can afford to wait for the real\n\u003e adversaries to show up on this one.\n\nAgreed. It's a classic \"it's not actually on fire *right now*\" problem,\nso it does keep getting pushed back.\n\nCheers,\nRusty.",
"sig": "50f2369c00f3dc576a30cbf118e1af1ae2a1e5ab1215c0cd25368bb60c6bdc27e0cb4c10e72cbdfbbb04477623ad9021fb88db5afc21c46f75603528d2f6ac4a"
}