Joost Jager <joost.ja...@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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
