"Fake Stake" Attacks on chain-based Proof-of-Stake cryptocurrencies

General
1

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.

2 Likes
2

and is CoinAge not checked in this case too?

3

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.

4

not sure what you mean by your question, when we check incoming POS block we verify that transaction does exist in transactions db. what would check of age of that transaction do to the matter?

5

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.

1 Like
6

An attacker’s block with stake amplification could not be valid because CoinAge is insufficient

7

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.

8

So, is Peercoin under attack now? On an average day, the Peercoin network carries 185 blocks now.

9

No, this is a fringe attack that would be more of an inconvenience than anything. The result would be nodes disconnecting, it would not affect the number of blocks per day.

10

but why is it not 144 blocks on an average day?

11

144 PoS, 24 PoW, and statistical deviation. I’m not sure why you think this has anything to do with the OP.

12

Block number is in constant flux, remember we have both PoW and PoS blocks and both PoS and PoW difficulty are in constant flux.

13

But last month, on an average day, the Peercoin network carries 185 blocks. And last year, 175 blocks on an average day.

14

So, the Peercoin network does not generate a block every 10 minutes, but every 8.57 minutes, if 144 PoS and 24 PoW blocks.

15

PoS is targeted at 1 per 10 min, so sure. Also remember that variances don’t add linearly, it tends to be something more aking to the square root of the sum of the squares.

16

So target time was crafted with only PoS blocks in mind? Maybe we should include, that there are also PoW blocks, and block time should be around 8.5 min?

17

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.