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
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.
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
> 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.
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.
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
> 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.
> 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.
you seem to be mixing up that mining pools expose tcp/8333 and if one pool's full node is attacked - many miners are caught in the crossfire unless in some type of special firewalled whitelist.
> you seem to be mixing up that mining pools expose tcp/8333 and if one pool's full node is attacked - many miners are caught in the crossfire unless in some type of special firewalled whitelist.
Mining pools don't typically expose tcp/8333 in a way that makes it easy for them to be targeted and when they do they typically have redundant nodes and other mitigation measures in place to ensure reliability.
There have additionally been high speed optimized block relay networks used in the past by mining pools, although I don't think they are used anymore due to the public p2p network being much faster and more reliable than in the past due to various protocol improvements.
