Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-27 📝 Original message: Matt Corallo <lf-lists at ...
📅 Original date posted:2022-04-27
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
>> This same problem will occur if *anyone* does ratelimiting, unless
>> *everyone* does. And with minisketch, there's a good reason to do so.
>
> None of this seems like a good argument for *not* taking the "send updates since the last sync in
> the minisketch" approach to reduce the damage inconsistent policies
> cause, though?
You can't do this, with minisketch. You end up having to keep all the
ratelimited differences you're ignoring *per peer*, and then cancelling
them out of the minisketch on every receive or send.
So you end up doing that LND and core-lightning do, which is "pick 3
peers to gossip with" and tell everyone else to shut up.
Yet the point of minisketch is robustness; you can (at cost of 1 message
per minute) keep in sync with an arbitrary number of peers.
So, we might as well define a preferred ratelimit, so nodes know that
spamming past a certain point is not going to propagate. At the moment,
LND has no effective ratelimit at all, so it's a race to the bottom.
We need that limit eventually, this just makes it more of a priority.
> I'm not really
> sure in a world where you do "update-based-sketch" gossip sync you're any worse off than today even
> with different rate-limit policies, though I obviously agree there are substantial issues with the
> massively inconsistent rate-limit policies we see today.
You can't really do it, since rate-limited junk overwhelms the sketch
really fast :(
Note, we *can* actually change the ratelimit in future, either by
running two sketches (feature bit!), or by changing the rate slowly
enough that they can handle the small differences.
Cheers,
Rusty.
Published at
2023-06-09 13:05:55Event JSON
{
"id": "ab2ab733897a68d77bb628c84fec89ba0f717c596ad458468c2a3adf9072cdd2",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315955,
"kind": 1,
"tags": [
[
"e",
"90c8a22893d09190339208f6b0eb636d6de40a2b6c7cff5708a261796a93b71e",
"",
"root"
],
[
"e",
"c6f5fc570ef1f0be1a7c00ddc6f2d9790bb0296a4d72b0c6f2798240b0f5f9fc",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2022-04-27\n📝 Original message:\nMatt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e\u003e This same problem will occur if *anyone* does ratelimiting, unless\n\u003e\u003e *everyone* does. And with minisketch, there's a good reason to do so.\n\u003e\n\u003e None of this seems like a good argument for *not* taking the \"send updates since the last sync in \n\u003e the minisketch\" approach to reduce the damage inconsistent policies\n\u003e cause, though?\n\nYou can't do this, with minisketch. You end up having to keep all the\nratelimited differences you're ignoring *per peer*, and then cancelling\nthem out of the minisketch on every receive or send.\n\nSo you end up doing that LND and core-lightning do, which is \"pick 3\npeers to gossip with\" and tell everyone else to shut up.\n\nYet the point of minisketch is robustness; you can (at cost of 1 message\nper minute) keep in sync with an arbitrary number of peers.\n\nSo, we might as well define a preferred ratelimit, so nodes know that\nspamming past a certain point is not going to propagate. At the moment,\nLND has no effective ratelimit at all, so it's a race to the bottom.\n\nWe need that limit eventually, this just makes it more of a priority.\n\n\u003e I'm not really \n\u003e sure in a world where you do \"update-based-sketch\" gossip sync you're any worse off than today even \n\u003e with different rate-limit policies, though I obviously agree there are substantial issues with the \n\u003e massively inconsistent rate-limit policies we see today.\n\nYou can't really do it, since rate-limited junk overwhelms the sketch\nreally fast :(\n\nNote, we *can* actually change the ratelimit in future, either by\nrunning two sketches (feature bit!), or by changing the rate slowly\nenough that they can handle the small differences.\n\nCheers,\nRusty.",
"sig": "3484ff9227b358299d90e0c372b2252b343f5898a4c112668dbd42e221f41d0c569180830340f67ade0f2e88e250ee7d437d5c72c55e7e66a5d17e88d7e8aa20"
}