Time itself is unimportant. The only reason the time is necessary is to allow you to iterate over something. I have been thinking about txn counts as an alternative clock.

Think about the following (ignore the double-spending issues for now, just think about txn-based time):

1) Txns have a block stamp t (i.e. rather than being independent of the blockchain, they must go in certain block t and cannot go in t-1 or t+1)
2) Certain types of txns can iterate the clock. Suppose that only txns that move 210 or more BTC iterate the clock.  [I just use BTC because it's familiar]
3) Suppose further that every txn requires a minimum fee, c>0. This means that each iteration has a minimum cost of c.
4) For for any block t, there are up to 100,000 possible clock iterations.  [because at most 21 million BTC could be moved in 100,000 210 BTC txns in a single block]
Iteration txns (anything with > 210 BTC inputs) are escrowed for 6 blocks before they can be spent again.
5) With any given iteration there is a chance of moving to block t+1 and starting the process over again.
6) Now for this to work as a timing mechanism we have to be sure that the probability that the clock runs out is 0. Suppose for example that the probability of success at any iteration is 0.01. In 10,000 iterations, this gives us a probability of 10,000 consecutive failures of 3*10^-44. This is effectively 0. Probably humanity is dead before the clock stops.
Note: A block includes not just the iterated txns, but also any number of smaller, fee-paying txns as well.

If we introduce this type of 'clock' into PPCoin it creates problems. Given a sizable stash of coin divided among different addresses, I can merrily mine blocks without any connection to the network, potentially overtaking the main chain with some probability. However, I think this problem can be overcome.

Think about the following process for block generation (similar to what I describe in the proof of stake wiki):
1) Any pair (block number, n) maps to a random lottery draw.  (where n is the number of iterations)
2) The lottery picks 4 random satoshis in sequence. The satoshi owners are invited to sign a block including any n iterated txns.
3) Let's say the 4 owners communicate via the network and agree to mine a block.
4) The first lottery winner creates a block and hashes it. Then he broadcasts the hash though the network. The other winners sign the hash and rebroadcast it.
5) Now the first lottery winner broadcasts the block together with the signed hash. [Note that one person can't modify the block because then the signature hash won't match. A conspiracy of these 4 guys could collude to generate many different blocks of the same height. One solution is to a) just pick one if we hear that someone has built on it. b) If not, combine any two duplicate blocks that build on the same root into a 'null block', ignore all txns in the 'null block', and build on the null block.]

If we have a process like this, it is hard to mine offline. Suppose for example suppose I have 10% of all coins. To mine a block offline I need to draw my own satoshis 4 times in a row. This takes about 10,000 iterations on average. With 10% of all coins, I can do up to 10,0000 iterations, so it within my capability. However, if I want to mine 6 blocks in a row it becomes much harder because of the escrow of txns. The problem is more complicated, but I'll just pretend I do this by dividing coins into 6 even piles. With 6 even piles, I can only do 1,667 iterations per block. This gives me a success probability of about 8% per block. For 6 blocks in a row that is about once every 4 million blocks.
 
On the other hand, consider legit public mining. Suppose 50% of coins are online. Then the success probability from one iteration is 6.25%. We would get a block about once every 16 iterations. That is very good.  If only 20% of coins are online, however, then we only get a block about once every 625 iterations. People could stir the pot if necessary by sending out some txns; perhaps that could be automated in the client. That should still be fine. If we drop lower than this, the iterations are going to blow up and double-spending risk becomes a problem. Thus, there needs to be strong incentives to keep coins online.

The incentives should be flexible. If 50% of coins are online then everything is hunky dory and the people who keep their coins offline do not need to be penalized.
One possibility is to issue a block reward that explodes in the number of iterations (e.g. the block reward = k*(average of iterations in recent blocks)^2). Iterations only explode if everyone is offline. Thus if we see lots of iterations, then we need to drastically increase incentives. Drastically increasing block reward redistributes wealth to whoever is online, solving the problem of offline coins (or lost coins). When hyperinflation is necessary, people who can't manage nodes would store their coins in an online bank that pays interest. The bank funds this by putting the coins online and earning interest.

Another interesting thing about this is it could be scheduled. Recall that the lottery draws are deterministic. If we approximately know who is online, then we can approximately know who will mine the upcoming blocks. This might allow for a rapid communication process and relatively quick blocks.

Anyways, there are kinks to be ironed out. The parameters need adjusting.

Are there some crippling issues that I am missing? I think that secret mining attacks are mostly covered here. Are there public attacks that will work?