What you described there doesn't prevent pooling, since the block could just be submitted to the pool, who could sign it. Though a non-randomized signature could be used by using its value in the target check.
Sorry it is late yes that was what I was trying to indicate. The PoW target check would be based on the signature of the block not the unsigned hash of the block (as it is now). There would be no need for a nonce field in the block header as the blockhash could remain constant. To provide efficient setup of the PoW the same hash could just be signed with a different k value. As a side note, ultimately it would lead to ECDSA mining asics. Still I agree the larger point was that I am pretty sure this would be a bad idea. It would massively raise the "barrier to entry" for small miners.
gmaxwell I am interested if you have any ideas on what could improve the decentralization of mining. They never will be adopted by Bitcoin, I am just curious as it has been something which has bugged me for a long time. The major advantage* of a using a pool with a higher hashrate (i.e. GHASH over BitMinter) is reduced variance. We can see by human behavior that most miners want to see a consistent source of revenue and if we assume that means a 95% confidence of getting at least 1 block per day that puts the lower bound of a viable pool at 3.3% [ P(X > 1) ~= 95% when λ = 4.75, 4.75/144 = 3.3% ]. Since a miner's major cost is electricity it is somewhat illogical to have a need for rewards everyday. As long as your actual reward approaches your expected reward in a 30 day period a smaller pool would be fine. Still it is hard to fight human psychology so lets start from an assumption that miners are uncomfortable mining in a pool which can't provide a reward at least once a day (say 95% confidence). Pools which fail to maintain at least 3.3% of global hashrate fail to meet the expectation of miners and thus have a net outflow of hashrate which creates a reinforcing cycle trending towards 0%. Even pools up to 3x that (say up to 10% of global reward) struggle. The pools above 10% usually are secure only failing due to minor attrition for non variance reasons. The bad news is that if 10% is the viable limit then we know it isn't going to end up as 10 pools with ~10% each.
One option which naively would seem to help would be more blocks in a day. At 2 minutes per block, for a pool to achieve the same 95% confidence of one or more blocks per day only requires 0.7% of the global reward. Of course lower block interval means more orphans and that means pools with better connectivity and higher hashrates are rewarded. So changes in protocol to reduce propagation times and resource requirements would be needed.
Another option I had considered (but would be unpopular with miners) would be a very long maturing period for coinbase rewards. If one had to wait 90 days to get/spend (depending on if pool does direct coinbase reward) block rewards, the daily variance would be less meaningful. Still miners have operating costs so maybe 90 days wouldn't be viable. Still 2016 blocks (14 days) could be or maybe some mechanism where the coinbase reward matures over a period of time (i.e. x% of reward becomes spendable over y days). The last one would require some changing to how block reward is created (maybe not creating a direct reward but rather a "token" of sorts which allowed the miner to redeem the reward over time).
Last thing I considered if what would be the impact if a p2pool type structure was native in the protocol. Would it be more heavily adopted? Could its usage be enforced (with majority support) and thus the precision of the block reward could be decoupled from the number of blocks.
Thoughts, errors, any other ideas?
There are other minor reasons for picking a larger pool but I am not sure if they can be overcome by protocol changes.
* Larger pools tend to be longer running pools and thus are trusted more (protocol changes that reduce operator trust requirement?)
* Larger pools tend to have better software and thus appealing user interfaces, statistics, features, charts, etc (better open source packages to share development resources and improve the quality of smaller pools ?)
* Larger pools tend to have more revenue and thus can afford more resources in the form of better servers, higher bandwidth, and better DDOS protection (protocol changes which reduce server load and improve DDOS resistance?)
* Not really a reason but miners may be ignorant and still believe a larger pool pays more ( better education? )
