It appears the automated checkpoint system comes directly from Peercoins automated checkpoints.  Of that I am no expert, but I will give you my thoughts.  Automated checkpoints do provide an extra layer of security, but at the same time, implementing such a system requires some give and take.  The entire idea behind Bitcoin was to provide decentralization through a peer consensus, but automated checkpoints, in this sense, require centralization.  In order to take the benefit of additional security that automated checkpoints provide, I must give up some decentralization. 

As I said earlier, I am no expert, but it seems to me that centralized, automated checkpoints have a central point of failure - the master checkpoint node.  What were to happen if the master node is down?  In the instance of an attack, it could go down by means of a sustained DoS.  While the checkpoint node is down, an attacker can begin to focus on the chain.  One other thing to note is that automated checkpoints are opt-in/opt-out.  If a portion of the network refuses to partake in the automatic checkpoints, that portion relies on a herd immunity of sorts to stay with the rest of the network.

I like to think of it like this: Locking the doors and windows to my house may keep a majority of criminals out, but the determined and skilled criminal will just need more time.


Try not to get yourself confused over the difference between a hard fork and a fork in the chain, or what you may call a soft fork.  A hard fork occurs by means of a protocol update.  Essentially, the old version will not be compatible with the new version.  This is what happened with Auroracoin at block 5400.  The old client still functions, but it will not be able to sync with the version of the chain the developer and community deem valid. 

When people like BCX talk about a fork in the chain, they are not referring to a hard fork.  I think this (https://en.bitcoin.it/wiki/Block_chain) provides a simple explanation of what a blockchain is.  If you direct your attention to the picture, you'll notice that the blockchain looks like a tree of sorts.  If we think of the current chain as the trunk of a tree, BCX has threatened to create multiple branches from that trunk.  Some clients may choose to follow one branch while other clients choose to follow a separate branch.  When competing chains exist in the wild, it is up to the developer to decide which chain is valid.  The chain may be rolled back and a checkpoint instituted. 

Forks occur every day in most blockchains, and typically this is a none issue.  This is what causes an orphaned block.  Even Bitcoin forks daily.  The issue, however, is that an attacker can release multiple chains into the wild and nobody knows which is the valid chain.  A chain can can be forked from either the last hard fork or the last checkpoint.  Without enough hash power to secure the chain, it is free reign from that point forward. 

The patch that you link to does nothing to solve the exploit in the KGW.  It does solve, however, a flaw in the linear difficulty re-targeting algorithms that were of common use prior to these past few months.  Bitcoin and Litecoin adjust difficulty in that manner.  For an understanding of what that patch fixes, read through the posts of the individual that wrote that patch.  ArtForz details the possible attack in the following thread: https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772

I urge you to read through this (https://bitcointalk.org/index.php?topic=505243.0)(https://bitcointalk.org/index.php?topic=504103.msg5573196#msg5573196) thread and pay specific attention to the posts belonging to Nite69.  Although BCX never comfirms that Nite69 is on the right track in uncovering the KGW flaw, he is.  If after reading through the two linked threads you still do not understand the flaw, I would be more than happy to try and explain it in greater detail.  

Edit: Although the original link provides some information, the meat of the discussion is in the new link I provide.

Any coin that implements the KGW is vulnerable to a time warp attack, and the only thing that can stop such an attack would be to have significantly more power than the attacker.  Then again, there is no way of knowing how much, if any, power would be needed until such an attack is attempted.  Furthermore, miners that do not have multiple pool or solo mining backups are doing the users of the coin a disservice.  Pools can be brought down, thus reducing the amount of power an attacker needs to fork a chain.  

This exploit is real, and it is only a matter of time before someone takes advantage of everyone's false sense of security.  People can hate on BCX or MarkM all they want, but I would urge those people to understand what they are truly trying to say.  MarkM consistently harps on the idea of hashing power, and for good reason.  If a PoW, blockchain based coin is to be taken seriously and used daily by people around the world, the chain needs to be secure.  The chain can only be secured with hashing.  If a chain is not secure, a malicious individual will attack it.  That is the reality of this world.  Honestly, each and every developer and user of a coin that implements the KGW should be thanking BCX for bringing to light the time warp flaw.  

I'm inclined to specifically agree with the bold portion of your post.  The developers have attempted to thwart an attack by reducing the median time-stamp from 11 blocks to 3 blocks and by reducing the time-stamp to current time difference from 2 hours to 20 minutes.  I still think this chain is vulnerable to an attack.  These preventative measures do make it more difficult to attack the chain by increasing the amount of time an attacker must spend building his own chain, but one must remember, an attacker will be working outside of time when he builds his chain.  In essence, he has all the time he needs.  If you combine a coordinated effort to make pools inaccessible with the assumption that most miners do not have multiple pools or solo-mining set as a back-up, this chain is still highly vulnerable.  Prove me wrong.