Matt Corallo <lf-li...@mattcorallo.com> writes: >> Allowing only 1 a day, ended up with 18% of channels hitting the spam >> limit. We cannot fit that many channel differences inside a set! >> >> Perhaps Alex should post his more detailed results, but it's pretty >> clear that we can't stay in sync with this many differences :( > > Right, the fact that most nodes don't do any limiting at all and y'all have a > *very* aggressive (by > comparison) limit is going to be an issue in any context.
I'm unable to find the post years ago where I proposed this limit and nobody had major objections. I just volunteered to go first :) > We could set some guidelines and improve > things, but luckily regular-update-sync bypasses some of these issues anyway > - if we sync once per > block and your limit is once per block, getting 1000 updates per block for > some channel doesn't > result in multiple failures in the sync. Sure, multiple peers sending > different updates for that > channel can still cause some failures, but its still much better. Nodes will want to aggressively spam as much as they can, so I think we need a widely-agreed limit. I don't really care what it is, but somewhere between per 1 and 1000 blocks makes sense? Normally I'd suggest a burst, but that's bad for consensus: better to say "just create your update N-6 blocks behind so you can always create a new one 6 blocks behind". >>> gossip queries is broken in at least five ways. >> >> Naah, it's perfect if you simply want to ask "give me updates since XXX" >> to get you close enough on reconnect to start using set reconciliation. >> This might allow us to remove some of the other features? > > Sure, but that's *just* the "gossip_timestamp_filter" message, there's > several other messages and a > whole query system that we can throw away if we just want that message :) I agree. Removing features would be nice :) >> But we might end up with a gossip2 if we want to enable taproot, and use >> blockheight as timestamps, in which case we could probably just support >> that one operation (and maybe a direct query op). >> >>> Like eclair, we don’t bother to rate limit and don’t see any issues with >>> it, though we will skip relaying outbound updates if we’re saturating >>> outbound connections. >> >> Yeah, we did as a trial, and in some cases it's become limiting. In >> particular, people restarting their LND nodes once a day resulting in 2 >> updates per day (which, in 0.11.0, we now allow). > > What do you mean "its become limiting"? As in you hit some reasonably-low > CPU/disk/bandwidth limit > in doing this? We have a pretty aggressive bandwidth limit for this kinda > stuff (well, indirect > bandwidth limit) and it very rarely hits in my experience (unless the peer is > very overloaded and > not responding to pings, which is a somewhat separate thing...) By rejecting more than 1 per day, some LND nodes had 50% of their channels left disabled :( This same problem will occur if *anyone* does ratelimiting, unless *everyone* does. And with minisketch, there's a good reason to do so. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
