Ok, you're definitely confused about the capabilities of someone with >50% of the hashing power. He cannot do things like put a 100BTC generation transaction per block. Such blocks are invalid and will be rejected by the network (particularly the nodes that actually accept bitcoins for goods and services). In other words, these will not be Bitcoin blocks - the rest of the network will happily continue to build the Bitcoin chain, while he enjoys his own isolated make-believe chain.
My example is wrong, since an incorrect bounty is something a node can check on its own. If you replace the setting by a double spend, it should work.
let's say that in this system a person with a computer finds one block per month. Then four people with a computer each should find a total of 4 blocks per month, right?.
Why?
If it wasn't clear, in this example the intention was that the 4 people aren't all there is, there are 4000 more similar people each finding 1 block per month, for a total of 4000 blocks per month. So again, if 4 people find 1 block per month each, then between them they find 4 blocks per month.
Why?
It is characteristic of non-parallelizable PoWs that they do not scale in the way you describe. I believe we have a misunderstanding here.
Because the pool shouldn't be the one deciding what goes in a block. As was explained, a pool is essentially just an agreement to share rewards.
Ok. Forget the pool as part of the argument here but think of parallel computing. The pool is a parallel computer.
The line of reasoning is about
parallel computation and scalability of the PoWs.With parallelizable PoWs, Bill Gates can buy as much computing power as he wants. He then changes a transaction in block 5 to his favour. Thanx to his computing power he easily can redo the entire block chain history since then. If the PoWs are, as I suggest, non-parallelizable, he simply cannot do better buy buying more computers. The only thing he can do is increase the clocking. By this, he can speed up his computation mabe by a factor of 5 or 10 - as opposed to buying more computers, where only money is his limit. So, non-parallelizable PoWs are an effective solution against this kind of attack.
(Yes, I know that the hashes of some 6 or so intermediate blocks are hardcoded in the bitcoin program and hence the attack will not work out exactly the way I described it - but this does not damage the line of reasoning in principle.)
Variance in block finding times is unwanted, but I think most will agree it pales in comparison to the other issues involved. Especially since there are basically two relevant timescales - "instant" (0 confirmations) and "not instant". The time for 10 confirmations follows Erlang(10) distribution which has less variance.
I do not think that the "variance in block finding times" is the essential advantage, it is rather convergence speed to "longest chain" (I have no hard results on this but am currently simulating this a bit) and better resistence against attacks which involve
pools parallel computers.
By all means you should pursue whatever research question interests you, but I expect you'll be disappointed both in finding a solution satisfying your requirements, and in its potential usefulness.
Trying to understand the argument. Do you think there is no PoW matching all the requirements? Care to give a hint why?
As to a potential usefulness: The concept is by now means "finished" but until now the discussion on the board proved very fruitful and helps to improve the system I am working on. This is for a different kind of block-chain application, so I am not expecting an impact for Bitcoin. Bitcoin is widely disseminated so I do not expect significant protocol changes to occur any time soon, especially by suggestions from outside the core team.