edit: the issue has been closed while the bug undergoes further review.
hi,
i will keep this concise as the attack is neither innovative nor sophisticated.
it is possible to slow and entirely halt external connections from communicating with a bitcoin-core node.
i don’t know whether peer connections remain open or frequently disconnect/reconnect. what happens to sync’d nodes with active peers is yet to be seen. it’s too early, at least for me, to know whether peers would drop a node under attack over timeouts and how bitcoind behaves with peers while tcp/8333 is under fire. so - further research required. this needs to be tested against sync’d nodes. there is a dos here - but also a (probably slim) possibility that a scaled attack would only result in new nodes being unable to enter the network.
it is accomplished by repeatedly sending a small request, e.g.
0x
1x
with thousands of concurrent socket requests. in this screen shot i’m using a handful of cheap digital ocean machines to attack 1 node.
as the script exhausts itself and finds trouble assigning itself open sockets the ddos becomes hit or miss in external requests. sometimes connecting, usually not connecting, and sometimes producing “black hole” events wherein it’s impossible to disconnect from an external telnet request until it drops you — which is atypical behavior. the attack works the best within the first 20 seconds of the attack script being launched - and so may require further optimization.
am i missing something? because i’m definitely able to stress my own nodes with this technique. it is my opinion that a botnet could probably tango down the bitcoin network - or at least slow finality considerably.
i’ve opted for full disclosure for a variety of reasons.
