Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-08 📝 Original message: > > >> > Isn't spam ...
📅 Original date posted:2019-11-08
📝 Original message:
>
> >> > Isn't spam something that can also be addressed by using rate limits
> for
> >> > failures? If all relevant nodes on the network employ rate limits,
> they
> >> can
> >> > isolate the spammer and diminish their disruptive abilities.
> >>
> >> Sure, once the spammer has jammed up the network, he'll be stopped. So
> >> will everyone else. Conner had a proposal like this which didn't work,
> >> IIRC.
> >
> > Do you have ref to this proposal?
> >
> > Imagine the following setup: a network of nodes that trust each other (as
> > far as spam is concerned) applies a 100 htlc/sec rate limit to the
> channels
> > between themselves. Channels to untrusted nodes get a rate of only 1
> > htlc/sec. Assuming the spammer isn't a trusted node, they can only spam
> at
> > 1 htlc/s and won't jam up the network?
>
> Damn, I searched for it but all the obvious keywords turned up blank.
> Conner CC'd in case he remembers the discussion and I'm not imagining it?
>
> Anyway, if there are 100 nodes in the network I can still open a channel
> to each one and jam it up immediately. And that's not even assuming I
> play nice until you trust me, then attack or get taken over.
At least it has gotten (100 times?) more difficult. I think it is hard to
say upfront how good or bad this setup would work. But I agree that prepay
deters spam in a more fundamental way.
Besides the argument that I brought up earlier of potentially killing
micro-payment-based use cases with prepay, there is also another concern.
It is nothing new, but could be interesting to look at it in the light of
prepayments.
It is currently possible to jam a channel with very limited resources. If
you hold 483 htlcs on a channel, it has become unusable for up to the cltv
limit. Let's say for 1000 blocks. If you allow a route that ping pongs back
and forth on the channel (let's say 8 times back and forth), you only need
to send 60 htlcs of the minimum amount for the route to jam the channel
completely. With min htlc policies of 1 sat, that will lock up only 60 sats
of the attacker (assuming no routing fees).
Let's say the wumbo channel has a capacity of 1 btc. Locking up 1 btc for
1000 blocks (~1 week) and assuming a time value of 4% per annum, the cost
to the routing node is: 1 * (1.04 ^ (1/52)) - 1 = 75,000 sats.
How much prepay would you need to prevent this? I don't think the 50 msat
would cut it.
I know this is the liquidity-using class of spam, but if prepay cannot
prevent this I think it is better to first address this class. And once
there is solution for that, see whether the other classes of spam are still
possible.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191108/70b303c9/attachment.html>;
📝 Original message:
>
> >> > Isn't spam something that can also be addressed by using rate limits
> for
> >> > failures? If all relevant nodes on the network employ rate limits,
> they
> >> can
> >> > isolate the spammer and diminish their disruptive abilities.
> >>
> >> Sure, once the spammer has jammed up the network, he'll be stopped. So
> >> will everyone else. Conner had a proposal like this which didn't work,
> >> IIRC.
> >
> > Do you have ref to this proposal?
> >
> > Imagine the following setup: a network of nodes that trust each other (as
> > far as spam is concerned) applies a 100 htlc/sec rate limit to the
> channels
> > between themselves. Channels to untrusted nodes get a rate of only 1
> > htlc/sec. Assuming the spammer isn't a trusted node, they can only spam
> at
> > 1 htlc/s and won't jam up the network?
>
> Damn, I searched for it but all the obvious keywords turned up blank.
> Conner CC'd in case he remembers the discussion and I'm not imagining it?
>
> Anyway, if there are 100 nodes in the network I can still open a channel
> to each one and jam it up immediately. And that's not even assuming I
> play nice until you trust me, then attack or get taken over.
At least it has gotten (100 times?) more difficult. I think it is hard to
say upfront how good or bad this setup would work. But I agree that prepay
deters spam in a more fundamental way.
Besides the argument that I brought up earlier of potentially killing
micro-payment-based use cases with prepay, there is also another concern.
It is nothing new, but could be interesting to look at it in the light of
prepayments.
It is currently possible to jam a channel with very limited resources. If
you hold 483 htlcs on a channel, it has become unusable for up to the cltv
limit. Let's say for 1000 blocks. If you allow a route that ping pongs back
and forth on the channel (let's say 8 times back and forth), you only need
to send 60 htlcs of the minimum amount for the route to jam the channel
completely. With min htlc policies of 1 sat, that will lock up only 60 sats
of the attacker (assuming no routing fees).
Let's say the wumbo channel has a capacity of 1 btc. Locking up 1 btc for
1000 blocks (~1 week) and assuming a time value of 4% per annum, the cost
to the routing node is: 1 * (1.04 ^ (1/52)) - 1 = 75,000 sats.
How much prepay would you need to prevent this? I don't think the 50 msat
would cut it.
I know this is the liquidity-using class of spam, but if prepay cannot
prevent this I think it is better to first address this class. And once
there is solution for that, see whether the other classes of spam are still
possible.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191108/70b303c9/attachment.html>;