Yeah I don't think you understand how modern DDOS work. The attacker hits your upstream provider with hundreds of GB/s of traffic, the simply null route you to deal with the flood. It is why DDOS are so hard to deal with. The pipe to your server simply becomes saturated beyond your bandwidth capabilities. You can't filter our the good nodes if they can't get to your server.
No I think I have a pretty good idea. Your explanation glosses over the nuances of DDoS, which in summary attempts to overload the resources available to an online service provider. DDoS is a progression from DoS (denial of service) which began as an attack on early websites with methods as simple as rapid requests. The defense was then to filter problematic IPs, which led to the attack becoming "distributed" where problem IP traffic blended with legitimate traffic. Complex sites, like heavily database driven ones (like MtGox for example), could be quickly overwhelmed.
Such DDoS, which is what I believe MtGox fell victim to, while more effective is generally less available because attackers must control a range of IP traffic. This is why I mentioned motivation and profitability being factors for DDoS. What I consider the most severe form of DDoS is what you refer to, where an attacker has access to such a large footprint of IP traffic (botnets) they can also impact the network layer of the service. Such an attack is non-trivial. Still, as I said, DDoS is not 100% effective. You can for example use a CDN like Akamai to distribute content with little worry of the network layer becoming clogged.
But all that is not so relevant to MBRs as I see it ("clearing houses" I feel mischaracterizes the function).
The MBR is an
addition to the network, not a component of it. Just as your car doesn't need nitrous oxide to run, but having it can improve engine capability, MBRs going down only means the network reverts to its performance without them (remember there can be many).
The idea that you know all miners so you can whitelist them is somewhat disconcerting as well. You have essentially created the central mining agency. The entity which all miners must work with to have any chance at efficient mining. Not really sure that is the "solution" as opposed to simply using a more efficient (large) block interval.
Again, MBRs are an addition to what's already there. Miners don't have to use them, and the consequence is the same as it would be for normal orphan rate.
You might take more time considering how to support the idea because I conceived it for Bitcoin too. I understand Bitcoin was seeing multi-minute block propagation time, which could worsen as the network expands. Orphaned blocks are a disincentive to any miner. MBRs simply look to solve network latency which exists due to decentralization.
I think we're more likely to see either no change and more reliance on off-chain txs and alt-coins to relieve scalability pressures and/or a modest increase (say to 5/10 MB once) or modest increases at future points.
Even at 10MB we are talking, a not so insignificant delay.
Still lets assume for a second you overcome the philosophical and vulnerability issues of a centralized clearing house. This still means a 2 hop propogation delay.
The critical window = (time to transmit to clearing house) + (time for clearing house to validate block) + (time to transmit to other miners) + (time for other miners to validate)
Today validating a 500 KB block can take upwards of 300 ms. 10MB would be more like 6000 ms. Lets assume protocol efficiencies cut that in half say 3000 ms. Remember there are two validations unless miners are just going to blindly (100% implicit trust) the data provided by the clearing house. Say the clearing house has 100 Mbps synchronous lot latency connectivity. The transmit time from miner to clearing house then becomes 5*8/100 = 0.4 seconds. If there are (a guess) 50 miners using the clearing house the time to transmit to the miners is another 50*10*8/100 = 40 seconds.
Under this naively optimistic scenario we are talking 0.4 + 3+ 40 + 3 = 46.3 seconds for full validation and double hop propagation to 50 mining peers. With Bitcoin's 600 second average block time this means an orphan rate of ~8%. With LTC it is more like 26%. With the idiotic 30 second block intervals used by some scamcoins it is something on the order of 80% orphans.
Now there are solutions to make block propagation more efficient. One (not possible on Bitcoin but could be used on an altcoin) would be to use a simplified transaction structure. I have done some modeling and see a roughly 60% reduction in block size is possible (i.e. 1.7x as many tx in the same sized block). For Bitcoin/Litecoin a soft fork where block is separated into header and tx set would allow more efficient pre-propogation of transactions. Still at the end of the day smaller block intervals are going to face scaling challenges much quicker and an increased loss of security due to orphans is inevitable.
I agree anything less than 2.5 minute block time is probably not practical. Still block size, block time, and network ability overall are factors which affect cryptocurrency in general. I still believe it's helpful to look at ways to improve usability and chance of success for cryptocurrency regardless of our different opinions on how that ultimately looks.
