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