From lf-lists at mattcorallo.com Mon Jul 4 02:07:16 2022 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Sun, 3 Jul 2022 22:07:16 -0400 Subject: [Lightning-dev] Onion messages rate-limiting In-Reply-To: References: <6s3T4U1P8_6q_O-FZaFN62RXzzbZuX8JMTNjq-7n9pxSt3HBTwrLBsk1u0Zj5UCxUf2l33X7d_XZAk9tCIgqbJDpbP048wfHBw837oh94b8=@protonmail.com> Message-ID: <42aaffe5-701d-14db-c8a0-c4cc8072ade3@mattcorallo.com> 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