Should LTC miners & pools block Amazon EC2 traffic?

[ElectricMucus]

There is this list:
http://www.webmasterworld.com/search_engine_spiders/4431323.htm

May be a bit redundant and dated, should we fish for more? In which case: Should we LTCers block EC2 traffic to make it easier to withstand BTXs announced attack? Anybody arguing over net neutrality?

204.236.128.0/17
75.101.128.0/17
50.16.0.0/14
184.72.0.0/15
174.129.0.0/16
107.20.0.0/14
66.40.52.0/24

That last one isn't ec2 - it's some provider in Florida - but it has crawled me with bots with the exact same signature of the rotating made up UA ec2 bots (you know, the Opera 9.90 guys) and I think owner of the bots live in that netblock and test from there, so I've got it down as a related netblock.


[Amazon EC2 - US East - Northern Virginia]
23.20.0.0/14 (23.20.0.0 – 23.23.255.255)
50.16.0.0/15 (50.16.0.0 - 50.17.255.255)
50.19.0.0/16 (50.19.0.0 - 50.19.255.255)
67.202.0.0/18 (67.202.0.0 - 67.202.63.255)
72.44.32.0/19 (72.44.32.0 - 72.44.63.255)
75.101.128.0/17 (75.101.128.0 - 75.101.255.255)
107.20.0.0/15 (107.20.0.0 - 107.21.255.255)
107.22.0.0/16 (107.22.0.0 - 107.22.255.255)
174.129.0.0/16 (174.129.0.0 - 174.129.255.255)
184.72.64.0/18 (184.72.64.0 - 184.72.127.255)
184.72.128.0/17 (184.72.128.0 - 184.72.255.255)
184.73.0.0/16 (184.73.0.0 – 184.73.255.255)
204.236.192.0/18 (204.236.192.0 - 204.236.255.255)
216.182.224.0/20 (216.182.224.0 - 216.182.239.255)

[Amazon EC2 - US West - Northern California]
50.18.0.0/16 (50.18.0.0 - 50.18.255.255) NEW
184.72.0.0/18 (184.72.0.0 – 184.72.63.255)
184.169.128.0/17 (184.160.128.0 - 184.169.255.255) NEW
204.236.128.0/18 (216.236.128.0 - 216.236.191.255)

[Amazon EC2 - US West - Oregon]
50.112.0.0/16 (50.112.0.0 - 50.112.255.255)

[Amazon EC2 - EU - Ireland]
46.51.128.0/18 (46.51.128.0 - 46.51.191.255)
46.51.192.0/20 (46.51.192.0 - 46.51.207.255)
46.137.0.0/17 (46.137.0.0 - 46.137.127.255)
46.137.128.0/18 (46.137.128.0 - 46.137.191.255) NEW
79.125.0.0/17 (79.125.0.0 - 79.125.127.255)
176.34.64.0/18 (176.34.64.0 – 176.34.127.255) NEW
176.34.128.0/17 (176.34.128.0 - 176.34.255.255)

[Amazon EC2 - Asia Pacific - Singapore]
46.51.216.0/21 (46.51.216.0 - 46.51.223.255)
46.137.224.0/19 (46.137.224.0 - 46.137.255.255) NEW
122.248.192.0/18 (122.248.192.0 - 122.248.255.255)
175.41.128.0/18 (175.41.128.0 - 175.41.191.255)

[Amazon EC2 - Asia Pacific - Tokyo]
46.51.224.0/19 (46.51.224.0 - 46.51.255.255)
46.137.192.0/18 (46.137.192.0 - 46.137.255.255)
103.4.8.0/21 (103.4.8.0 - 103.4.15.255)
175.41.192.0/18 (175.41.192.0 - 175.41.255.255)
176.32.64.0/19 (176.32.64.0 - 176.32.95.255)
176.34.0.0/18 (176.34.0.0 - 176.34.63.255) NEW

[Amazon EC2 - South America - Sao Paulo]
177.71.128.0/17 (177.71.128.0 - 177.71.255.255) NEW

'Amazon_EC2_Asia', '103.4.12.0/22'
'Amazon_EC2_Asia', '103.4.8.0/22'
'Amazon_EC2_N_America', '107.20.0.0/14'
'Amazon_EC2_N_America', '107.22.0.0/16'
'Amazon_EC2_S_America', '122.248.192.0/19'
'Amazon_EC2_N_America', '174.129.0.0/16'
'Amazon_EC2_S_America', '175.41.128.0/19'
'Amazon_EC2_S_America', '175.41.192.0/19'
'Amazon_EC2_Asia', '175.41.224.0/19'
'Amazon_EC2_Europe', '176.32.64.0/21'
'Amazon_EC2_Europe', '176.34.0.0/21'
'Amazon_EC2_S_America', '177.71.128/17'
'Amazon_EC2_N_America', '184.169.128.0/17'
'Amazon_EC2_N_America', '184.72.0.0/15'
'Amazon_EC2_N_America', '204.236.128.0/17'
'Amazon_EC2_N_America', '216.182.224.0/20'
'Amazon_EC2_N_America', '23.20.0.0/14'
'Amazon_EC2_Europe', '46.137.0.0/17'
'Amazon_EC2_Europe', '46.137.128.0/18'
'Amazon_EC2_Europe', '46.137.192.0/21'
'Amazon_EC2_Europe', '46.137.224.0/21'
'Amazon_EC2_Europe', '46.51.192.0/20'
'Amazon_EC2_Europe', '46.51.216.0/21'
'Amazon_EC2_Europe', '46.51.224.0/21'
'Amazon_EC2_N_America', '50.112.0.0/16'
'Amazon_EC2_N_America', '50.16.0.0/14'
'Amazon_EC2_N_America', '67.202.0.0/18'
'Amazon_EC2_N_America', '72.44.32.0/19'
'Amazon_EC2_N_America', '75.101.128.0/17'
'Amazon_EC2_Europe', '79.125.0.0/18'

8.18.144.0 - 8.18.145.255
23.20.0.0 - 23.23.255.255
46.51.128.0 - 46.51.255.255
46.137.0.0 - 46.137.255.255
50.16.0.0 - 50.19.255.255
50.112.0.0 - 50.112.255.255
67.202.0.0 - 67.202.63.255
72.21.192.0 - 72.21.223.255
72.44.32.0 - 72.44.63.255
75.101.128.0 - 75.101.255.255
79.125.0.0 - 79.125.127.255
87.238.80.0 - 87.238.87.255
103.4.8.0 - 103.4.15.255
107.20.0.0 - 107.23.255.255
122.248.192.0 - 122.248.255.255
174.129.0.0 - 174.129.255.255
175.41.128.0 - 175.41.255.255
176.32.64.0 - 176.32.127.255
176.34.0.0 - 176.34.255.255 (latest entry dated Feb 23)
184.72.0.0 - 184.73.255.255
199.255.192.0 - 199.255.195.255
204.236.128.0 - 204.236.255.255
207.171.160.0 - 207.171.191.255
216.182.224.0 - 216.182.239.255

[coblee]

Blocking EC2 won't prevent any attack. He can just have a non-EC2 machine talk with his EC2 instances to get the forked chain and have that non-EC2 machine broadcast the longer chain to all pools and miners.

[Simran]

Blocking EC2 won't prevent any attack. He can just have a non-EC2 machine talk with his EC2 instances to get the forked chain and have that non-EC2 machine broadcast the longer chain to all pools and miners.

Actually have an option a whole lot more efficient than that.

~BCX~

BCX, do you not have anything else to do besides just be on these forums? It's like you refresh the page every second and reply extremely fast.

[ElectricMucus]

Blocking EC2 won't prevent any attack. He can just have a non-EC2 machine talk with his EC2 instances to get the forked chain and have that non-EC2 machine broadcast the longer chain to all pools and miners.

Right, but it would still make it harder, since if he had a genuine botnet he wouldn't need ec2 and if we don't do it we will have to deal with EC2 traffic and the other machines under his control.

[coblee]

Blocking EC2 won't prevent any attack. He can just have a non-EC2 machine talk with his EC2 instances to get the forked chain and have that non-EC2 machine broadcast the longer chain to all pools and miners.

Right, but it would still make it harder, since if he had a genuine botnet he wouldn't need ec2 and if we don't do it we will have to deal with EC2 traffic and the other machines under his control.

I think most people don't understand a 51% attack. His fork will be mined in secret. So his EC2 instances and botnets and gpus will not be talking to any machine on the main network during the duration of the attack. Only when he is releasing the longer chain, would one of his machine need to announce the chain to everyone. So during the attack, you will not notice anything like an increase in hashrate.

[ElectricMucus]

Blocking EC2 won't prevent any attack. He can just have a non-EC2 machine talk with his EC2 instances to get the forked chain and have that non-EC2 machine broadcast the longer chain to all pools and miners.

Right, but it would still make it harder, since if he had a genuine botnet he wouldn't need ec2 and if we don't do it we will have to deal with EC2 traffic and the other machines under his control.

I think most people don't understand a 51% attack. His fork will be mined in secret. So his EC2 instances and botnets and gpus will not be talking to any machine on the main network during the duration of the attack. Only when he is releasing the longer chain, would one of his machine need to announce the chain to everyone. So during the attack, you will not notice anything like an increase in hashrate.

Well you could change the behavior of the clients in that respect. Assuming a fork this could halt propagation.
It would have to be a quick fix though.

Plus it would block certain ddos methods. (Doing that from EC2 could get one jail but BTCX wouldn't mind, it's probably part of the thrill)

[crazy_rabbit]

Blocking EC2 won't prevent any attack. He can just have a non-EC2 machine talk with his EC2 instances to get the forked chain and have that non-EC2 machine broadcast the longer chain to all pools and miners.

Right, but it would still make it harder, since if he had a genuine botnet he wouldn't need ec2 and if we don't do it we will have to deal with EC2 traffic and the other machines under his control.

I think most people don't understand a 51% attack. His fork will be mined in secret. So his EC2 instances and botnets and gpus will not be talking to any machine on the main network during the duration of the attack. Only when he is releasing the longer chain, would one of his machine need to announce the chain to everyone. So during the attack, you will not notice anything like an increase in hashrate.

+10000

I wish the BTC-E chat room would spend a bit more time trying to understand how that which they prize so much, actually works.

[ElectricMucus]

I haven't said that.

If you send synfloods from EC2 to a pool which blocks you they don't have to worry about resources for non-spoofed packets, any good DDOS protection from an ISP does the rest.

Disclaimer: I am not part of the btc-e chatroom. And I was initially thinking about BTCX initial threat of tring to rise the hashrate and then dropping out.
Plus my suggestion on changing the clients behavior in that respect still stands. Just some reasonable restriction on what a host is expected to do under normal circumstance would be a start.

[ElectricMucus]

I haven't said that.

If you send synfloods from EC2 to a pool which blocks you they don't have to worry about resources for non-spoofed packets, any good DDOS protection from an ISP does the rest.

EC2's won't be used to DDoS LOL.......where did you get that idea?

You, increasing your thrill power-level. How about some higher stakes? Wouldn't be as much fun if there isn't the threat of jail time...

[wndrbr3d]

He's not going to use EC2. If he's serious about it, he'd post proof.

Executing this kind of attack on LTC from EC2 will cost THOUSANDS of dollars, and if he's using his companies resources to try and do it for "free", he's an idiot.

THAT being said, let's not get hasty because I host my private pool in EC2