pbear2k21

you may be correct. the issue has been closed for further review. a scaled attack might only prevent new nodes from entering the network as existing connections would be spared even when the maximum limit of peers is reached.

however - and i mean this - you need to watch your mouth buddy. you've been unnecessarily rude. i have decided not to respond with force - so either stfu or press your luck

i don't guard my reputation. this isn't 48 laws of power. i'd never become a blockchain socialite to the extent of social climbing to become blockstream's cto. i answer to no one and don't try to mold how others perceive me. interesting insults though - though i can assure you wholeheartedly that you don't want to make it personal. just so you know where you stand, who i am and who pulls rank on who. i rce'd slack too. bitcoin is food now. there is a dos here regardless - but thanks for the motivation

>Do your homework! You're not the first person who ever thought of attacking a bitcoin node. While I'm sure there are areas for improvement, you're not likely to be able to make useful suggestions from a position of almost total ignorance.

again, i've successfully found remote crashes and dos issues in 25 - 30 blockchains. i don't care if you're a biased developer who takes this to heart. i'm going to see to brutalizing bitcoind and making it clear to you what happens when i attack nodes. cocky academics like you motivate me. he who laughs last etc.

i've popped 25 - 30+ blockchains. from anecdotal experience i suspect that there could be something here and need to see it through with a sync'd node and more firepower. you seem overconfident.

inaccessible to external machines that are not participating in the attack. it's yet to be seen what happens to a node that's sync'd with active peers and whether a node under attack is kicked out of the network for timeouts or how bitcoind behaves in general while tcp/8333 is under fire.

i considered this and needed clarification. i didn't know whether the p2p connections remained open or made frequent disconnect/reconnects. 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, how bitcoind behaves with peers while tcp/8333 is experiencing stress, etc.

node operators can implement their own throttling - sure - but how many bitcoin node operators are doing that to deflect a p2p ddos attack? even if some are, most aren't - and finality in the network could potentially suffer as a result of a massively scaled botnet attack.

edit: interesting child comment here. not pushing a patch just leaves the bulk of the network vulnerable to being ddos'd by a botnet - potentially resulting in severely lagged finality at best. ip throttling can/should be implemented by being baked into bitcoind.

bitcoind not having ip associated throttling edit: BUILT IN* is questionable. this attack shouldn't work on out-of-the-box installs of bitcoin. as i mentioned earlier - there is no rationale behind a single machine making 1k handshake requests per second.

it is

50k sockets looping requests make the p2p port entirely inaccessible at times. with more attacking machines it is reasonable to suspect that the target node(s) could be held down in perpetuity.

edit: re: child comment / syn flood; sure. bitcoind needs ip associated throttling baked in. there is no rationale behind a single machine attempting 1k handshakes a second. the attack shouldn't work at all.