I haven't read the whole thread, but it appears you want to stabilize the price of a bitcoin with the dollar, based on the estimated number of CPUs mining. This has 3 major problems, imo: 1) it doesn't protect against dollar inflation (which isn't terrible, but if the fed prints more dollars so does bitcoin), 2) estimating the number of CPUs is difficult if not impossible with the bitcoin proof-of-work design, 3) the security/continuity/dependability of the network still relies on massive amounts of hashing power, and always will. Bitcoin also has terrible scalability issues.
I wasn't trying to tie it to the dollar per se, that was just an example for the initial stabilization phase. The coin's price will essentially be tied to the global average electricity cost. So if global electricity suddenly got 10% cheaper (eg. new invention) all coins will lose 10% of their value and be worth, for example, 90 cents each (and vice-versa). I find that a very reasonable drawback though, not to mention unavoidable. But if the fed prints a trillion dollars tomorrow that will make the dollar cheaper, so it'll cost people more cents per Kilowatt worldwide, so the coins remain essentially unchanged.
Although it's not in the proposal yet, I did mention somewhere in this thread I came up with a very reasonable solution to not require hashing power at all: let merchants put their money on the line to secure the network, and in return, refund most or all of their mandatory transaction fees. So if the economy is completely stable, no hashing power is necessary.
But who will the merchants pay their money for to acquire bitcoin credit? How will it be decentralized? My suggestion keeps everything in the current design intact except for the number of coins each new block will contain. That's why I believe it requires very simple modification to the current code, plus it will be just as familiar to the existing audience.