The statement in the article is that we are vulnerable to attack two:
Concern A : Check 1 ensures that the coin exists, but NOT that it is unspent. This insight immediately leads to the vulnerability we discuss next.
Concern B : Even if we’re validating a block on a fork of the main chain, the coinstake transaction is validated against the TxDB for the main chain itself.
Response of some of our team:
This is a valid concern. The node has a structure in memory holding all seen stake, setStakeSeen and setStakeSeenOrphans, but that structure does not persist between runs of program and only knows about coinstake it seen this session.
The simplest solution would be to store setStakeSeen structure in db.
Can someone some up with a use case? I think i’ve seen “check coinstake failed” on testnet after my node switches to the different fork/chain but the node validates new blocks against the abandoned chain (which my node has in its db).
In the past its annoying, i just re-sync from a good node.
that’s a different matter, if you end up on the wrong fork for long enough time you won’t be able to reconcile without resync because coin stake modifier selection window would have closed and the other fork coin stake modifiers are unreachable.
The coinage would add the same as the stake amplifying (arguably they mean ‘coinday amplification’ rather than ‘stake amplification’ in the context of peercoin). Checking coinage doesnt really help the problem at all. Also, there is nothing that stops the attacker from simply waiting a bit longer after selling of their stake before attacking.
Target PoS time and target PoW time are both parameters in the code, with 10 min and 60 min respectively. We should not change these parameters, as they have a large effect on the security and function of the chain.
Again, this is quite off topic from the ‘fake stake’ attack in the OP.