📅 Original date posted:2018-01-20
📝 Original message:
As mentioned in the text, this is imposed by you on each peer that connects to you. The point is to prevent a single peer from consuming all your memory and CPU and prevent you from servicing legitimate peers- i.e. it prevents denial of service using a single peer and forces attackers to use a *distributed* denial of service.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message --------
On January 18, 2018 7:03 PM, <7riw77 at gmail.com> wrote:
>
>
>> You impose this 25 channels per peer. I start opening a channel to
>> you. Because I did not check mempool or because my fee-estimation algo is
>> bad, I pay too low a fee. I become impatient and bump it up, which you
>> perceive as another open (so it is now 2/25 channels).
>
> It seems, to me, that this example could be pretty easily extended to 1000, or 2000, or -- pretty much anything. In fact, this brings up an important'ish point, possibly. If every channel I "try to open," and then fail to, counts as resources of any kind on the receiver, we've just added a perfect attack surface for a denial of service. However this is arranged, it needs to be arranged in a way that does not have (or at least has a minimal number of) fixed pool of resources/magic numbers of any kind that can be exhausted, after which things "no longer work." To do otherwise is to practically invite someone taking the entire network down with a well-planned/executed process that exhausts this resource across a large number of critical nodes (and there will be critical nodes -- it's just a part of graph theory that this will happen).
>
> 😊 /r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180119/3c21300b/attachment.html>;
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:48:28
in reply to nevent1q…ke94
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:48:28Event JSON
{
"id": "2e1b79be0e5ebaf68a2bb23ab83308d639fd8f32c45a83388f362aff8727998d",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686314908,
"kind": 1,
"tags": [
[
"e",
"2a4926c7999f60c613526723369cef244df2cc105602a16cdb8a4a5833ba7a81",
"",
"root"
],
[
"e",
"db0b992afd726d92f0b779752cbbf5a368140ca1fe56262653d6af9bf1cb8a81",
"",
"reply"
],
[
"p",
"71ee7d50cfca84b0c16b6892ca51fcfcf7556b903ca505a902e8a434c67533fa"
]
],
"content": "📅 Original date posted:2018-01-20\n📝 Original message:\nAs mentioned in the text, this is imposed by you on each peer that connects to you. The point is to prevent a single peer from consuming all your memory and CPU and prevent you from servicing legitimate peers- i.e. it prevents denial of service using a single peer and forces attackers to use a *distributed* denial of service.\n\nRegards,\nZmnSCPxj\n\nSent with [ProtonMail](https://protonmail.com) Secure Email.\n\n-------- Original Message --------\nOn January 18, 2018 7:03 PM, \u003c7riw77 at gmail.com\u003e wrote:\n\n\u003e\n\u003e\n\u003e\u003e You impose this 25 channels per peer. I start opening a channel to\n\u003e\u003e you. Because I did not check mempool or because my fee-estimation algo is\n\u003e\u003e bad, I pay too low a fee. I become impatient and bump it up, which you\n\u003e\u003e perceive as another open (so it is now 2/25 channels).\n\u003e\n\u003e It seems, to me, that this example could be pretty easily extended to 1000, or 2000, or -- pretty much anything. In fact, this brings up an important'ish point, possibly. If every channel I \"try to open,\" and then fail to, counts as resources of any kind on the receiver, we've just added a perfect attack surface for a denial of service. However this is arranged, it needs to be arranged in a way that does not have (or at least has a minimal number of) fixed pool of resources/magic numbers of any kind that can be exhausted, after which things \"no longer work.\" To do otherwise is to practically invite someone taking the entire network down with a well-planned/executed process that exhausts this resource across a large number of critical nodes (and there will be critical nodes -- it's just a part of graph theory that this will happen).\n\u003e\n\u003e 😊 /r\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180119/3c21300b/attachment.html\u003e",
"sig": "172541270ff9f4fb537e41ef94eeeeb8240e840ebc63dad277a161a2bded8771c790b788b9e27e16e1dc72ad9e89293fadac5bc505a26129be69e0f5050a88de"
}