Oh noes. Someone can keep downloading data from a server. Someone call the cops.
This is a big nothing-burger. The "attacker" has to actively sustain downloading the data being requested. No amplification, no anything making it anything but a nuisance. Just a lamer that discovered that they can keep making requests in a loop in a Python script.
Sure, some per-IP rate-limiting might be desirable there (but has to be balanced against new nodes being able to download the history), but any service exposing data on the public Internet can be DDoSed by just making requests to it from multiple IPs, and that's why so many companies hide behind Cloudflare.
This "attack" might rake some fees on people hosting public nodes in the cloud (just like about any http server, S3 bucket etc.), but that's about it. Lots of nodes don't accept incoming connections, communicate via Tor, network relays, etc. so this has absolutely no chance of making any dent in the network as a whole.
the conclusion of your argument is "this has absolutely no chance of making any dent in the network as a whole" which is faulty. much of the network is hosted by providers that charge for upstream overage: https://bitnodes.io/nodes/?q=ipv4#networks-tab. if a pool's full node is tcp/8333 exposed or a conventional full node is attacked on a vuln host there will be financial/operational consequences. this attack is a "nothing-burger" until botnet skids demonstrate otherwise.
This script asks a node for the 2000 headers between block 783,569 and 785,568.
It's normal for a node to request headers in chunks of 2000, either as part of syncing the entire chain from scratch, or when catching up after being offline for more than two weeks.
It's not the most efficient (asymmetric) way to waste bandwidth either. For each ~100 byte header request you get a 160 KB reply. You can instead ask for a block using a shorter message and get up to 4 MB. This way you can download the entire blockchain at 500+ GB multiple times.
Those with limited upload bandwidth (and for some reason not behind a NAT) can use -maxuploadtarget to limit the total upload.
I'm not sure how the available bandwidth is distributed between peers, but it's generally quite hard to dominate all connections of all nodes (search for "eclipse attacks"), even with a botnet [0].
So that leaves CPU draining as a possible goal (or stealing Bitcoin from random script kiddies who run untrusted code and dependencies from the internet).
[0] = which isn't free, probably not their most economic use case and some of their operators may not like it when you attack a cryptocurrency they themselves may want to use
> "there is a remote attack that can be carried out in perpetuity against vulnerable nodes in a way that a single attacking machine can force dogecoind to upload > 130MB/s to the attacking machine in a sustained way."
This appears to be a description of a theoretical attack to cause a specific target networked Bitcoin node to consume quite a bit of bandwidth by returning blockchain data to the attacker. It doesn't seem like this would have any effect on the Bitcoin network at large, however. While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".
>While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".
it meets all of the criteria to be called, bluntly, a remote financial attack/exploit that much of the network is vulnerable to
[+] [-] globalreset|2 years ago|reply
This is a big nothing-burger. The "attacker" has to actively sustain downloading the data being requested. No amplification, no anything making it anything but a nuisance. Just a lamer that discovered that they can keep making requests in a loop in a Python script.
Sure, some per-IP rate-limiting might be desirable there (but has to be balanced against new nodes being able to download the history), but any service exposing data on the public Internet can be DDoSed by just making requests to it from multiple IPs, and that's why so many companies hide behind Cloudflare.
The total rate limiting seems to be already implemented: https://notatether.com/academy/how-to-limit-bandwidth-of-bit...
This "attack" might rake some fees on people hosting public nodes in the cloud (just like about any http server, S3 bucket etc.), but that's about it. Lots of nodes don't accept incoming connections, communicate via Tor, network relays, etc. so this has absolutely no chance of making any dent in the network as a whole.
[+] [-] pbear2k23|2 years ago|reply
[+] [-] sprovoost|2 years ago|reply
It's normal for a node to request headers in chunks of 2000, either as part of syncing the entire chain from scratch, or when catching up after being offline for more than two weeks.
https://github.com/bitcoin/bitcoin/blob/fc06881f13495154c888...
It's not the most efficient (asymmetric) way to waste bandwidth either. For each ~100 byte header request you get a 160 KB reply. You can instead ask for a block using a shorter message and get up to 4 MB. This way you can download the entire blockchain at 500+ GB multiple times.
Those with limited upload bandwidth (and for some reason not behind a NAT) can use -maxuploadtarget to limit the total upload.
I'm not sure how the available bandwidth is distributed between peers, but it's generally quite hard to dominate all connections of all nodes (search for "eclipse attacks"), even with a botnet [0].
So that leaves CPU draining as a possible goal (or stealing Bitcoin from random script kiddies who run untrusted code and dependencies from the internet).
[0] = which isn't free, probably not their most economic use case and some of their operators may not like it when you attack a cryptocurrency they themselves may want to use
[+] [-] ftxbro|2 years ago|reply
[+] [-] adastra22|2 years ago|reply
[+] [-] crnkovic|2 years ago|reply
[+] [-] pbear2k23|2 years ago|reply
not theoretical https://github.com/dogecoin/dogecoin/issues/3243 - i've attacked several of my own nodes. anyone could launch a botnet against the actual network
>to cause a specific target networked Bitcoin node to consume quite a bit of bandwidth by returning blockchain data to the attacker.
correct
>It doesn't seem like this would have any effect on the Bitcoin network at large
until a botnet or botnets make huge swaths of the mining network unprofitable https://bitnodes.io/nodes/#networks-tab
>While I don't doubt that there exists an obscure client vulnerability that could be patched, it seems far-fetched and alarmist to categorise this as a "bitcoin exploit".
it meets all of the criteria to be called, bluntly, a remote financial attack/exploit that much of the network is vulnerable to
[+] [-] nightshadetrie|2 years ago|reply
[+] [-] pbear2k23|2 years ago|reply
[+] [-] alphabet9000|2 years ago|reply
[+] [-] mr_woozy|2 years ago|reply
[deleted]
[+] [-] codehalo|2 years ago|reply