Thanks a lot, this is very interesting. To problem #1: What exactly is meant with consensus failure and how does it affect network security? So if I have a faked time stamp that is t seconds in the future, how much less coins do I need to perform a 51% attack?
This is the means to generating hashes for PoS for PPC (paraphrased a little):
int64 nTimeWeight = min((int64)nTimeTx - txPrev.nTime, (int64)STAKE_MAX_AGE) - nStakeMinAge);
CBigNum bnCoinDayWeight = CBigNum(nValueIn) * nTimeWeight / COIN / (24 * 60 * 60);
if (!GetKernelStakeModifier(blockFrom.GetHash(), nStakeModifier, nStakeModifierHeight, nStakeModifierTime, fPrintProofOfStake))
return false;
ss << nStakeModifier;
ss << nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n << nTimeTx;
hashProofOfStake = Hash(ss.begin(), ss.end());
if (CBigNum(hashProofOfStake) > bnCoinDayWeight * bnTargetPerCoinDay){
return hashProofOfStake; } // Golden "nonce" found, we have a block!
else {return false;}
You can game this in a bunch of ways. If you're building your own chain of blocks, you can manipulate the timestamp; BlackCoin uses 10 minute intervals, so there's another 600 chances right there (+ 10 min). If you want to build lots of blocks, you need coinstake distributed in lots of places (nTimeBlockFrom << nTxPrevOffset << txPrev.nTime << prevout.n).
Now you can bruteforce a chain of length whatever privately so long as you have a bunch of coinstake at different addresses, and then doublespend using that. Unless everyone is trying to do this, you don't need 51% stake to do this -- just the hoarding of a bunch of stake and some bruteforcing at an exacting time and you can doublespend. This is why PoS in PPC and friends defaults to PoW; you're just manipulating a bunch of different factors in search of golden "nonces" (manipulations of non-nonce parameters) in a chain of blocks instead of simply increasing the nonce.
Using PoW blocks to make stake modifiers can also help prevent you from being able to game this a bit from the "if (!GetKernelStakeModifier(blockFrom.GetHash(), nStakeModifier, nStakeModifierHeight, nStakeModifierTime, fPrintProofOfStake)) return false;" portion, but I don't think it completely eliminates the risk.
Sunny King at some point mentioned changing confirmation rules from number of blocks that have passed to the amount of coinage that has been included in blocks since a transaction has taken place ("trust score"). But this still doesn't solve the "nothing at stake" forking problem, and you can still likely doublespend in that case with <51% stake.