📅 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>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 13:06:35
in reply to nevent1q…2vy6
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 13:06:35Event JSON
{
"id": "f96e00cf27ee0ca0ded1f619e5e06a8ce5093489c731aec7ac691ab800a75c7e",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315995,
"kind": 1,
"tags": [
[
"e",
"add1c4290260e2dc63c6102c94233677cad0a1290347eea023c4a78984a8e64d",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2022-07-01\n📝 Original message:\nHi Val,\n\n\u003e Another huge win of backpressure is that it only needs to happen in DoS\n\u003e situations, meaning it doesn’t have to impact users in the normal case.\n\nI agree, I think the same would apply to prepayments as well (0 or 1 msat in\ncalm times). My main concern with relying _only_ on backpressure rate\nlimiting is that we'd end up w/ your first scenario more often than not,\nwhich means routine (and more important to the network) things like fetching\ninvoices becomes unreliable.\n\nI'm not saying we should 100% compare onion messages to Tor, but that we\nmight\nbe able to learn from what works and what isn't working for them. The\nsystems\naren't identical, but have some similarities.\n\nOn the topic of parameters across the network: could we end up in a scenario\nwhere someone is doing like streaming payments for a live stream (or w/e),\nends up fetching a ton of invoices (actual traffic leading to payments), but\nthen ends up being erroneously rate limited by their peers? Assuming they\nhave 1 or 2 channels that have now all been clamped down, is waiting N\nminutes (or w/e) their only option? If so then this might lead to their\nlivestream (data being transmitted elsewhere) being shut off. Oops, they\njust\nmissed the greatest World Cup goal in history! You had to be there, you\nhad to\nbe there, you had to *be* there...\n\nAnother question on my mind is: if this works really well for rate limiting\nof\nonion messages, then why can't we use it for HTLCs as well?\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220701/bb864893/attachment.html\u003e",
"sig": "91a8bbf14ac8962658e7707611c6a354b784a4b60c25c23f8cb1c036a3f0b1c6337d1b1354e0c6c2256af76307d4b0f51e337e1cd28e3ca665e4c10bf956aa91"
}