Quickfix could be adding a check for low blocktime and increase the banscore with 10. That way clients would disconnect from clever after 10 fast blocks for 1 day because the default ban limit is 100. Easy to implement, dynamic and not centralized.
I would get behind this. You're 100% correct in that this would be an easy implementation. The only thing I would worry about is forked side chains from people not updating their clients. The breakdown looks good now, but before the 130 update, there were a lot of people on old wallets. Of course, you would just ban versions older than the newest as well.
Not a bad idea, thsminer.
-Fuse
I think this (thsminer's idea of banning miners with fast blocks by using the banscore) would cause chain splits and net splits. Imagine that clever is connected to 2 peers: a and b, those 2 peers will block clever after 10 blocks. Clever will then connect to two other peers to relay their blocks: c and d. c,d will relay clevers blocks to a,b. After 10 fast blocks c,d will block clever, but more importantly: a,b will block c,d. This goes on and at the end of the day the network is splitted into several groups of peers and miners are divided accross those, causing multiple chain forks to be mined.
Conceptually; the idea of banning a miner after too many fast blocks have been mined would work. But the question is: how to effectively ban while keeping the network safe. (again: proxying is really really simple, and banning blocks of IP's won't really help).
thanks
