Hey all,
Thanks for the comments!
Here are a few answers inline to some points that aren't fully addressed
yet.
@laolu
> 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?
Because HTLC DoS is
On Sun, Jul 10, 2022 at 9:14 PM Matt Corallo
wrote:
> > It can also be considered a bad thing that DoS ability is not based on a
> number of messages. It
> > means that for the one time cost of channel open/close, the attacker can
> generate spam forever if
> > they stay right below the rate
On 7/10/22 4:43 AM, Joost Jager wrote:
It can also be considered a bad thing that DoS ability is not based on a number of messages. It
means that for the one time cost of channel open/close, the attacker can generate spam forever if
they stay right below the rate limit.
I don't see why
On Thu, Jun 30, 2022 at 4:19 AM Matt Corallo
wrote:
> Better yet, as Val points out, requiring a channel to relay onion messages
> puts a very real,
> nontrivial (in a world of msats) cost to getting an onion messaging
> channel. Better yet, with
> backpressure ability to DoS onion message links
Hi Bastien,
Thanks for the proposal,
While I think establishing the rate limiting based on channel topology
should be effective to mitigate against DoS attackers, there is still a
concern that the damage inflicted might be beyond the channel cost. I.e, as
the onion messages routing is
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).
On 7/1/22 9:09 PM, Olaoluwa Osuntokun wrote:
Hi Matt,
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable cost that an attacker cares about without
> impacting the system's usability due to said cost.
Applying this statement to related a
Hi Matt,
> Ultimately, paying suffers from the standard PoW-for-spam issue - you
> cannot assign a reasonable cost that an attacker cares about without
> impacting the system's usability due to said cost.
Applying this statement to related a area, would you also agree that
proposals
to introduce
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
One further note, I don’t think it makes sense to specify exactly what the
rate-limiting behavior is here - if a node wants to do something other than the
general “keep track of last forwarded message source and rate limit them” logic
they should be free to, there’s no reason that needs to be
Thanks Bastien for writing up the proposal, it is simple but effective I
think.
>> One issue I see w/ the first category is that a single party can flood the
>> network and cause nodes to trigger their rate limits, which then affects
>> the
>> usability of the onion messages for all other
Thanks for your inputs!
One issue I see w/ the first category is that a single party can flood the
> network and cause nodes to trigger their rate limits, which then affects
> the
> usability of the onion messages for all other well-behaving parties.
>
But that's exactly what this proposal
Thanks Bastien for writing this up! This is a pretty trivial and straightforward way to rate-limit
onion messages in a way that allows legitimate users to continue using the system in spite of some
bad actors trying (and failing, due to being rate-limited) to DoS the network.
I do think any
Heya Laolu,
From my PoV, adding prepayments to onion messages is putting the cart before
the horse a bit, think there's a good amount of recourse before resorting to
that.
Seems there are two cases to address here:
1. People are trying to stream GoT over lightning
In this case, just rate
Hi t-bast,
Happy to see this finally written up! With this, we have two classes of
proposals for rate limiting onion messaging:
1. Back propagation based rate limiting as described here.
2. Allowing nodes to express a per-message cost for their forwarding
services, which is described here
15 matches
Mail list logo
