I will start with the time problem.
Client need to accept block when they arrive, if you open your client the block 2 days old need to b accepted with the timestamp in it so current time is not usefull. the ay it is done is that the blocks are validate to not be too much in future and not too much in the past. the future is now 30 minutes from now. ACp remove this but it would not be impossible for someone without acp to begin to mine at the last block of a retarget with a time way in the future and then release the chain only when in time range, and continue his chain with a lower retarget.
the 9% been small help us here a bit, but lets make an example with the old 1.41 so we get a very easy to see example. let say the network is at 503 block of a low diff at 160 and will retarget at 225 for a 12h run. the attacker begin to mine at the 503 and put in his not yet release chain the 504 block 18 hour later in fact getting 1.41 down to 113 as it is a 504 with 30h. so he can mine a chain with significantly lower hash rate then the network and get a longer chain(30%). he can release his chain after the 18h are pass with all his new chain at a small time after the first one to get back the 160 retarget and repeat.
let say he release after 20h so his block are 2 hour old. since it’s block are in the past the client can only validate against the surrunding chain. else any client that is at some point isolate from the network would not be able to reorganize and get back to the “concensus” chain.
so what is used is that a block can’t go back in time from the mean of the previous one and if get now can’t get in future too much. (machine time can be off in time a bit even when using NTP as it use drift and not instantaneous corrections). the fact is that the miner put the time in the block, normal client would put correct time a rogue one can put what he want and unless it is certified(signed) no one can verify what is put is real at the time it is pu. other can only validate the it’s in range so possibly valide.
on a side note window and most network credential exchanged like kerberos, saml, etc usually use a ± 15 minutes window for token as time can vary and delay can happen. so validating in a range is standard way in distributed environment.
so what we have it’s an orphaning of a long part of the chain. and this is what ACP prevent as you can’t do it more then 3 blocks old. time can still be manipulate but would be difficult to sustain even with more then 50%. a limit has been added for the past time to be less then one hour before the last block so the legitimate network should never be able to make a current time block been checkpointed. so the legitimate network should never be able to find 3 locks in row before they get orphan by the attacker. this would approximatly require more then 75% of the hashrate to be possible with greater the 90% chance of success over a 20h period. and he attacker would not benefit form been on a lower diff chain for more the 3 blocks.
setting a min max time between block is not an option! few seconds between 2 blocks is possible and like we had in may 1 hour between 2 blocks is also possible (we don’t want that but still something that unfortunately can happen).
one technic exists that is the digital timestamping where an authority sign a timestamp with a hash to prove it was done at that time. in fact that is what the block chain do in a decentralise way so using a centralize timestamper don’t make sense in my mind. this only prevent you from stamping the hash at another point in time but it don’t prevent you from waiting a long time before timestamping it. if used to construct next block it will prevent precalculation to orphan chain with wrong timestamp. not orhaning it.
time is one manipulation that most miner see, long chain orphaning has way more bad side one of then is double spend, another is reject any transaction to be confirm. so long orphan should be prevented. so the question that most would say is why allow reorganize? the reason is that you can be on the wrong fork (as some pool have been and possibly some client still are in the pre client 0.6.4.4 protocol chain and are in around block 88300) so when they update they need to reoganize and get to the new chain. this is one easy to understand example, but other reason can make a client follow a “wrong” chain. The big question is how to make sure the “concensus” chain is not replace. the actual solution is ACP and is what should be enhanced, replace ,etc. by something more decentralize.
the bitcoin protocol concider that you can’t get enough power to overtake the network, this was possibly a good assomption for bitcoin as it was and as it is still the principal coin. for alt this is not true as hash power of attacker is enough to overtake the coins when time correctly.
so a form of checkpointing need to be done, but by the network not by a central authority. similarly to the current mining network isolation and other glitches makes the decentralization of checkpointing a difficult task. you can’t just let the network checkpoint if you get a network split you can get two checkpoint at same blocks height for 2 different block and then your screwed.
POS is a form of checkpointing and have been discuss and implement in many coin. each having some change in the way POS is used. some consume the coin age, some just use it. but in all if you get a significant amount of coins sitting for long time you can make a POS 51% attack (it’s 51% of the vote not 51% of the coins). since not all coins are used in POS a 51% can take a lot less then 51% of the total coins especially when it consume coin age as timing in use of coin age can make a POS 51% possible with less then 1% of the coin and it is known that 3-4 address has more then 300K coin from the 30000-40000 blocks and still have not move them(6oADBx5Xxhc273rnppgNDP4dHzgrsbtxjE from 33789 is one of them and the coins are 3 transactions away from coins used in the attacks so possibly still on the hand of the attacker).
I’ll continue in next few days as my time for today is over. I need to go to sleep. but should be enough to start some discussion