Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-03 📝 Original message: On 7/1/22 8:48 PM, ...

📅 Original date posted:2022-07-03
📝 Original message:
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