📅 Original date posted:2019-11-07
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> In my opinion, the prepayment should be a last resort. It does take away
> some of the attractiveness of the Lightning Network. Especially if you need
> to make many payment attempts over long routes, the tiny prepays do add up.
> For a $10 payment, it's probably nothing to worry about. But for
> micro-payments this can become prohibitively expensive. And it is exactly
> the micro-payment use case where Lightning outshines other payment systems.
> A not yet imagined micro-payment based service could even be the launchpad
> to world domination. So I think we should be very careful with interfering
> with that potential.
I completely agree, yeah. And maybe we'll never need it, but it's one
of my main concerns for the network.
> Isn't spam something that can also be addressed by using rate limits for
> failures? If all relevant nodes on the network employ rate limits, they can
> isolate the spammer and diminish their disruptive abilities.
Sure, once the spammer has jammed up the network, he'll be stopped. So
will everyone else. Conner had a proposal like this which didn't work,
IIRC.
> If a node sees that its outgoing htlc packets stack up, it can reduce
> the incoming flow on the channels where the htlcs originate
> from. Large routing nodes could agree with their peers on service
> levels that define these rate limits.
Unfortunately, if we *don't* address this, then the network will defend
itself with the simple tactic of deanonymizing payments.
And every other solution I've seen ends up the same way :(
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:57:12
in reply to nevent1q…5zpz
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:57:12Event JSON
{
"id": "6fa15895de04247b630cac2d62133f95292a29280dc15974887ef79f6ffa4d78",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315432,
"kind": 1,
"tags": [
[
"e",
"0c91e21e034533f122e94b0fd3031654ae905512e27a1262e64ae8c7923a76b8",
"",
"root"
],
[
"e",
"ad57c0ebc24184f4072a41a542bea2f31c94914d052023fbef126ddb1325cbfc",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2019-11-07\n📝 Original message:\nJoost Jager \u003cjoost.jager at gmail.com\u003e writes:\n\u003e In my opinion, the prepayment should be a last resort. It does take away\n\u003e some of the attractiveness of the Lightning Network. Especially if you need\n\u003e to make many payment attempts over long routes, the tiny prepays do add up.\n\u003e For a $10 payment, it's probably nothing to worry about. But for\n\u003e micro-payments this can become prohibitively expensive. And it is exactly\n\u003e the micro-payment use case where Lightning outshines other payment systems.\n\u003e A not yet imagined micro-payment based service could even be the launchpad\n\u003e to world domination. So I think we should be very careful with interfering\n\u003e with that potential.\n\nI completely agree, yeah. And maybe we'll never need it, but it's one\nof my main concerns for the network.\n\n\u003e Isn't spam something that can also be addressed by using rate limits for\n\u003e failures? If all relevant nodes on the network employ rate limits, they can\n\u003e isolate the spammer and diminish their disruptive abilities.\n\nSure, once the spammer has jammed up the network, he'll be stopped. So\nwill everyone else. Conner had a proposal like this which didn't work,\nIIRC.\n\n\u003e If a node sees that its outgoing htlc packets stack up, it can reduce\n\u003e the incoming flow on the channels where the htlcs originate\n\u003e from. Large routing nodes could agree with their peers on service\n\u003e levels that define these rate limits.\n\nUnfortunately, if we *don't* address this, then the network will defend\nitself with the simple tactic of deanonymizing payments.\n\nAnd every other solution I've seen ends up the same way :(\n\nCheers,\nRusty.",
"sig": "27b865a06266564ec13b55ce630a182cc04950c32780236a840e459018b5e30dae451cf7a9ce00a29a8aefb4198c2afdd4e0a475496dccf0157d28e1fbf07e77"
}