I think you misunderstood what i said. By considering IP range/block, that would force attacker to have diverse collection of IP address which make the attack more costly. So the software wouldn't connect to multiple IP in close range (e.g. 10.10.2.2 and 10.10.253.253).
That would mean only one customer per ISP can get paid to run a node. One way or another, this is a terrible "solution" for something that isn't even a problem.
Good point. I forgot about rewarding node when creating earlier reply.
I think you misunderstood what i said. By considering IP range/block, that would force attacker to have diverse collection of IP address which make the attack more costly. So the software wouldn't connect to multiple IP in close range (e.g. 10.10.2.2 and 10.10.253.253).
OK, but what would be the most feasible IP subnet to restrict?
/8 is too wide (and obviously won't do).
/24 is too narrow given the size of the Bitcoin network and will probably end up accomplishing nothing.
Even having max one connection per /16 subnet is going to create issues with syncing for some unfortunate users, who will have to spend a bit more time downloading more slowly.
Honestly i don't know which subnet most feasible. But it seems Bitcoin Core these days use combination of /16[1], ASN[1] and various protocol[2] (such as IPv4, IPv6 and Tor).
Although having said all that, someone could just purchase 1024 IP addresses at many different cloud computing vendors in different regions and even if the simulation only runs for an hour or something, the effects of it being used maliciously will easily be seen by at least part of the network.
And as i stated earlier, it should be more expensive than buying bulk of IP address on certain range.
[1]
https://github.com/bitcoin/bitcoin/pull/16702[2]
https://github.com/bitcoin/bitcoin/pull/27213