Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-07 📝 Original message: Joost Jager <joost.jager ...
📅 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.
📝 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.