Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-01 📝 Original message: Hi Val, > Another huge ...
📅 Original date posted:2022-07-01
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/bb864893/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/bb864893/attachment.html>;