On 7/1/22 8:48 PM, Olaoluwa Osuntokun wrote:
Hi Val, > Another huge win of backpressure is that it only needs to happen in DoS > situations, meaning it doesn’t have to impact users in the normal case. I agree, I think the same would apply to prepayments as well (0 or 1 msat in calm times). My main concern with relying _only_ on backpressure rate limiting is that we'd end up w/ your first scenario more often than not, which means routine (and more important to the network) things like fetching invoices becomes unreliable.
You're still thinking about this in a costing world, but this really is a networking problem, not a costing one.
I'm not saying we should 100% compare onion messages to Tor, but that we might be able to learn from what works and what isn't working for them. The systems aren't identical, but have some similarities.
To DoS here you have to have *very* asymmetric attack power - regular ol' invoice requests are trivial amounts of bandwidth, like, really, really trivial. Like, 1000x less bandwidth than an average ol' home node on a DOCSIS high-latency line with 20Mbps up has available. Closer to 1,000,000x less if we're talking about "real metal".
More importantly, Tor's current attack actually *isn't* a simple DoS attack. The attack there isn't relevant to onion messages at all, you're just throwing up roadblocks with nonsense here.
On the topic of parameters across the network: could we end up in a scenario where someone is doing like streaming payments for a live stream (or w/e), ends up fetching a ton of invoices (actual traffic leading to payments), but then ends up being erroneously rate limited by their peers? Assuming they have 1 or 2 channels that have now all been clamped down, is waiting N minutes (or w/e) their only option? If so then this might lead to their livestream (data being transmitted elsewhere) being shut off. Oops, they just missed the greatest World Cup goal in history! You had to be there, you had to be there, you had to *be* there...
You're basically making a "you had to have more inbound capacity" argument, which, sure, yes, you do. Even better, though, onion messages are *cheap*, like absurdly cheap, so if you have enough inbound capacity you're almost certain to have enough inbound *network* capacity to handle some invoice requests, hell, they're a millionth the cost of the HTLCs you're about to receive anyway...this argument is just nonsense.
Another question on my mind is: if this works really well for rate limiting of onion messages, then why can't we use it for HTLCs as well?
We do? 400-some-odd HTLCs in flight at once is a *really* tight rate limit, even! Order of magnitudes tighter than onion message rate limits need to be :)
Matt _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
