Either way, this is not equivalent to introducing trust into the system where it did not exist before. My claim about proof-of-stake not being trust any more than proof-of-work is stands.
I was proposing using coin days destroyed as part of the "difficulty" computation, which would mean they actually DO have value, since you cannot use the same coin days more than once, and they would reduce the number of CPU cycles you need to burn in order to produce a block. The idea is to reduce the cost of mining in terms of pure CPU cycles by giving value to something that currently has no value: coin days. So you actually CAN do such math still.
This is not a pure proof-of-stake system, though. I am as skeptical of pure proof of stake as you are.
I'm more strongly in favor of using citizen's ID's as provided by governments for the purpose of voting on blocks than in proof of stake.Not knowing you, this doesn't tell me much, since the same could be said of the most statist friend I actually tolerate, the one who thinks Bitcoin should die in a fire. I'm guessing that this means "not in favor of it at all."
There are a couple of problems people are trying to solve with proof-of-stake. The first is that the value of mining will eventually go down, meaning people will be willing to devote less computing power to it, reducing the cost of an attack.
The second is that, even if it didn't go down, we don't necessarily want a huge fraction of the world's computing power devoted to mining.
The goal is to take some limited resource that doesn't depend on a trusted third party and that is difficult to corner and use that to distribute voting authority.
In addition, we'd like the people doing the voting to have an economic incentive to vote correctly.
Bitcoin does that by paying them to vote and revoking the payment if their block doesn't end up in the main chain.
Proof-of-stake does it by hoping that the voters care about the integrity of the system, similar to only allowing landowners to vote, only (hopefully) without the ability to prevent others from becoming stakeholders, which I think is your main worry about it.
Incidentally, the coin days are from ALL of the transactions in the block, not just your own. I'm not sure if I was clear about that before.
You could maybe override a transaction that had fewer coin days, but you'd have to burn a similar amount (though less) of CPU time in addition.
Speaking of which, is there any reason peers couldn't watch for forks and incorporate any still-valid transactions into new blocks and permanently blacklist any outputs that get double-spent? You could create a special "blacklist" transaction that just incorporates the two separate spends into the main chain, so that everyone could validate that the account holder attempted to double spend.