[crnkovic]

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".

[pbear2k23]

>This appears to be a description of a theoretical attack

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

[jameshilliard]

You can connect to basically any normal web server/service and waste their bandwidth/resources in the same way by downloading data they provide publicly.

If you think this is a real vulnerability I'd suggest you report it to any project like that, a proof of concept exploit would basically involve curl in a while loop with the output going to /dev/null.

Here's an incomplete list of applications that should also have this vulnerability that you can start going through: https://en.wikipedia.org/wiki/Comparison_of_web_server_softw...

[pbear2k23]

that's actually not correct. apples and oranges. we're talking about mining rigs - not websites and apps maintained by sysadmins who can apply a simple fix or waf during an upstream overage attack. if this was a non-issue they wouldn't be patching it https://github.com/dogecoin/dogecoin/issues/3243

[jameshilliard]

> that's actually not correct. apples and oranges. we're talking about mining rigs - not websites and apps maintained by sysadmins who can apply a simple fix or waf during an upstream overage attack.

Bitcoin mining rigs don't even use bitcoin p2p protocol themselves, they typically use stratum protocol(https://braiins.com/stratum-v1/docs) and don't accept incoming connections from the public internet generally. They usually connect to mining pool servers which have long had various forms of ddos attack mitigation systems in place.

> if this was a non-issue they wouldn't be patching it https://github.com/dogecoin/dogecoin/issues/3243

They added an integrated basic bandwidth limiter from the looks of it, one can do something like that using external tools already. Hardly a real vulnerability.

[pbear2k23]

it's an issue. it shouldn't be possible to pull a range of 2000 block headers in an unthrottled way from a remote bitcoin node. while you make some valid points - i find it humorous that you have tasked yourself with defining what constitutes a security vulnerability. furthermore - you may want to examine https://bitnodes.io/nodes/ and come to a realistic figure of how many machines running bitcoind aren't accepting tcp/8333 from 0.0.0.0

[jameshilliard]

> it's an issue. it shouldn't be possible to pull a range of 2000 block headers in an unthrottled way from a remote bitcoin node.

Bulk header requesting is used as part of the initial block download, that's literally how it's designed to work: https://developer.bitcoin.org/devguide/p2p_network.html#head...

> while you make some valid points - i find it humorous that you have tasked yourself with defining what constitutes a security vulnerability.

Pretty much every internet connected service can be attacked with various forms of volumetric denial of service attacks, there are many mitigation measures available, you've implemented the bitcoin p2p protocol attack equivalent of curl in a while loop, that's not really something one would typically consider to be a real vulnerability.

> furthermore - you may want to examine https://bitnodes.io/nodes/ and come to a realistic figure of how many machines running bitcoind aren't accepting tcp/8333 from 0.0.0.0

First of all it's trivial to create fake nodes that show up on sites like that so I wouldn't really trust the numbers there, also it's easy for bitcoin users to add more real nodes if/when needed due to an attack, similar to how one can add more cloud application servers when there is a load increase or ddos attack on a web service the bitcoin network can add nodes if/when there is a need to mitigate these types of attacks.

[crnkovic]

> if this was a non-issue they wouldn't be patching it

As far as I can tell, nobody is claiming it's a 'non-issue'. Rather, it's a minor issue with an impact that is greatly exaggerated or sensationalised by the person reporting it.

[pbear2k23]

>it's a minor issue with an impact that is greatly exaggerated or sensationalised by the person reporting it.

until, again, a botnet makes huge swaths of the bitcoin network unprofitable.

this is computer science - not how you feel about or faultily interpret an exploit.

[jameshilliard]

> until, again, a botnet makes huge swaths of the bitcoin network unprofitable.

You seem to be mixing up bitcoin nodes and bitcoin miners.