Quote from: Forp on October 06, 2011, 09:07:55 AM

So the idea was to replace the proof-of-work problem in Bitcoin (which currently is highly parallelizable) by a problem which is not parallelizable at all. (As outlined, this is only part of the concept, because a completely serialized proof-of-work would not lead to the probabilistic behaviour we want).

Hope I got the point where I lost you.

You fail to explain why a completely serial Proof-of-work would be better than the current system. As others have pointed out, a serial proof-of-work has two major problems:

Fastest node wins every time. If you think FPGAS are scary now, wait till they are optimized for your serial problem. (Actually, an ASIC may be needed to achieve a higher clock speed). If high clock-speed paid, I might just invest in liquid nitrogen cooling for 5+GHz clock-rates.
Verification requires the proof-of-work to be repeated by every node. If there are two competing POWs sumbitted, the network must stall until at least 1 is verified. Some nodes may elect to blindly start the next proof-of-work without verification, but that only compounds the problem.

Edit2: That machine I mentioned earlier would still be able to do better than most competing nodes. It would be able to verify 32 Proof-of-work candidates in parallel, while speculatively generating a "proof-of-work" block based on each.

Edit: You brought up trust. It appears you want to eliminate "wasted" computations by having a distributed central authority choose the winner ahead of time. If that is the case, why use proof-of-work at all?