It is so tiring to reply to the hordes of ignorant trolls.
I wrote upthread that one could buy and sell the coins on an exchange. They would then hold the historic private keys to attack with. This would only cost them the average spread between buy and sell prices, so they don't actually have to buy 50%.
Even monsterer doesn't claim that collecting historic priv keys is a viable attack vector. It was explained why it isn't. He claims that it's easy to collect enough priv keys for this attack in a short timeframe.
There is no way to objectively distinguish a historic key that is respent from a historic transaction that had spent that historic key. This is a double-spend with two chains arguing about which was first.
The only way to distinguish which was first is either a decentralized objectivity which is the PoW longest-chain-rule, or for PoS a centralized objectivity such as community/developer checkpoints.
Please stop wasting my time with nonsense replies.
The problem is not to acquire a historic key and make a doublespending transaction, the problem is to acquire enough historic keys to outweigh the honest stake. When you acquire the first key, you must start your fork before it was emptied. In the scenario you describe, your fork must start very far in the past, but that's not a problem. The problem is, you now have a transaction that must be censored on your fork (in your scenario it's the transaction that deposits the funds back to an exchange). Since this transaction (let's call it transaction A) is excluded from your fork, you must exclude all transactions that depend on it, i.e. a transaction B that spends that output, and all descendant transactions (that's all on your fork, the main fork continues to function as it supposed to). Now, when you make the second withdrawal from the exchange, it may happen, that you must exclude this withdrawal on your fork too, because it indirectly depends on the transaction A, so you fail to acquire new keys this time. If the second withdrawal doesn't depend on transaction A, than OK, you got the second key, but you must again censor depositing transaction on your fork, therefore your fork inevitably drifts away from the main fork and it becomes more and more difficult to find suitable keys. Given that for a successful attack you need a lot of stake/keys, the only plausible scenario is to acquire them all in a very short timeframe.
P.S. I don't know, whether my explanation is easy to understand, English isn't my native language. If it's not clear enough, maybe other people may help you (most people here seem to understand this issue with this kind of attack).