Timedrift exploit on PoS coins to increase minting probability

[Thireus]

From [HYP] HyperStake | Generous Reward Staking | Advanced Staking Controls & Wallet

Every coin has a setting "timedrift". It is meant to allow nodes that are for one reason or another a bit out of sync with the median time, to be able to submit blocks and still be fine.

For example peercoin allows a time drift of 2 hours, and same with NovaCoin. HoboNickels, BottleCaps, HyperStake are all 15 minute timedrift allowance.

So when you are attempting to stake and meet the staking target, you create 60 hashes at once per UTXO if you are using standard peercoin hashing code. The only thing that changes from hash to hash is the input for time. It hashes 60 seconds into the future at once. This system works pretty good, and doesn’t really have much problem.

The problem is that when you get someone that tweaks the code, and says “why not hash 2 hours into the future” I will have 7,200 hashes to attempt to stake instead of 60 hashes". So this code tweakers chance of staking is actually 11,900% more likely to hit a hash (did I do the math correctly? I think I did).

[…]

What I failed to realize is that this would really screw up difficulty. Let’s say the code tweaker above hashed two hours into the future, submitted the stake, and the network accepted it with no problems. The next block would calculate difficulty by taking that 2 hour future stake and subtracting the last time before that, calculating the time to stake as 2 hours between the two blocks. The difficulty code thinks that this means that people are having trouble staking, and the diff drops.
[…]

Any thoughts?

[thehuntergames]

interesting theory,

it may give the tweaked nodes an edge if it is required that next blocks must have a later timestamp than the current last one. (normal ones wont be able to stake one unless 2 hours have passed)

But the bigger gap time difference that may lower the diff occurs only once, if all nodes were tweaked it wouldnt work

–update–
spend a few moments looking at CBlock* CreateNewBlock(CReserveKey& reservekey, CWallet* pwallet, bool fProofOfStake)

the timestamp comes from the transaction, which is what anybody can send. It makes the attack a lot harder

[mably]

[quote=“thehuntergames, post:2, topic:3338”]interesting theory,

it may give the tweaked nodes an edge if it is required that next blocks must have a later timestamp than the current last one. (normal ones wont be able to stake one unless 2 hours have passed)

But the bigger gap time difference that may lower the diff occurs only once, if all nodes were tweaked it wouldnt work

–update–
spend a few moments looking at CBlock* CreateNewBlock(CReserveKey& reservekey, CWallet* pwallet, bool fProofOfStake)

the timestamp comes from the transaction, which is what anybody can send. It makes the attack a lot harder[/quote]

Here is the related code for those interested:

https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/main.cpp#L3630
https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/wallet.cpp#L1213

[pillow]

There is time-drift attack myth:

Pillow's Peercoin Myths

[mably]

[quote=“pillow, post:4, topic:3338”]There is time-drift attack myth:

Pillow's Peercoin Myths

And the related sigmike answer here: http://www.peercointalk.org/index.php?topic=2634.msg22660#msg22660

Thanx for the link pillow.

[presstab]

Hey guys, cool to see you already linked to my findings. I have a full article released about it here: http://bitcoinist.net/interview-presstab-pos-vulnerabilities/

There is no myth about this problem, anyone can hash with about a 12,000% advantage on the current PPC code and be completely within the bounds of the protocol. I think that if PPC were wise, it would instead of saying “this is not a problem”, just go ahead and change the timedrift variable. It is not hard.

Also keep in mind that the most significant risk about this problem, in my opinion, is the impact on difficulty. If everyone runs this code, block target will be significantly overshot.

[Thireus]

[quote=“presstab, post:6, topic:3338”]Hey guys, cool to see you already linked to my findings. I have a full article released about it here: http://bitcoinist.net/interview-presstab-pos-vulnerabilities/

There is no myth about this problem, anyone can hash with about a 12,000% advantage on the current PPC code and be completely within the bounds of the protocol. I think that if PPC were wise, it would instead of saying “this is not a problem”, just go ahead and change the timedrift variable. It is not hard.

Also keep in mind that the most significant risk about this problem, in my opinion, is the impact on difficulty. If everyone runs this code, block target will be significantly overshot.[/quote]

Hi presstab,

Thank you for posting here. Could you share with us your thoughts about which timedrift value we should use, and what would be the consequences (apart from preventing this attack).

Cheers.

[presstab]

[quote=“thehuntergames, post:2, topic:3338”]interesting theory,

it may give the tweaked nodes an edge if it is required that next blocks must have a later timestamp than the current last one. (normal ones wont be able to stake one unless 2 hours have passed)[/quote]

Curious why you think that the code requires this. Please elaborate if you would.

[presstab]

[quote=“Thireus, post:7, topic:3338”][quote=“presstab, post:6, topic:3338”]Hey guys, cool to see you already linked to my findings. I have a full article released about it here: http://bitcoinist.net/interview-presstab-pos-vulnerabilities/

There is no myth about this problem, anyone can hash with about a 12,000% advantage on the current PPC code and be completely within the bounds of the protocol. I think that if PPC were wise, it would instead of saying “this is not a problem”, just go ahead and change the timedrift variable. It is not hard.

Also keep in mind that the most significant risk about this problem, in my opinion, is the impact on difficulty. If everyone runs this code, block target will be significantly overshot.[/quote]

Hi presstab,

Thank you for posting here. Could you share with us your thoughts about which timedrift value we should use, and what would be the consequences (apart from preventing this attack).

Cheers.[/quote]

We changed HyperStake from 15 minutes timedrift to 60 seconds. Giving a binary to all of our peers that allowed 5 minute hashdrift created a major decrease in difficulty and overshooting targets by more than double. 60 seconds seems natural because A) that is what the standard ppc client is hashing into the future anyways, so it shouldn’t change much of how the network is operating B) there is reason to have some drift allowance, slow internet connections, etc.

BLK and some other coins are using 15 second. Not sure how that is going, but I would assume high orphan rate. Even our new 60 second drift is creating a bit higher orphan rate, but nothing absurd.

[Thireus]

[quote=“presstab, post:9, topic:3338”][quote=“Thireus, post:7, topic:3338”][quote=“presstab, post:6, topic:3338”]Hey guys, cool to see you already linked to my findings. I have a full article released about it here: http://bitcoinist.net/interview-presstab-pos-vulnerabilities/

There is no myth about this problem, anyone can hash with about a 12,000% advantage on the current PPC code and be completely within the bounds of the protocol. I think that if PPC were wise, it would instead of saying “this is not a problem”, just go ahead and change the timedrift variable. It is not hard.

Also keep in mind that the most significant risk about this problem, in my opinion, is the impact on difficulty. If everyone runs this code, block target will be significantly overshot.[/quote]

Hi presstab,

Thank you for posting here. Could you share with us your thoughts about which timedrift value we should use, and what would be the consequences (apart from preventing this attack).

Cheers.[/quote]

We changed HyperStake from 15 minutes timedrift to 60 seconds. Giving a binary to all of our peers that allowed 5 minute hashdrift created a major decrease in difficulty and overshooting targets by more than double. 60 seconds seems natural because A) that is what the standard ppc client is hashing into the future anyways, so it shouldn’t change much of how the network is operating B) there is reason to have some drift allowance, slow internet connections, etc.

BLK and some other coins are using 15 second. Not sure how that is going, but I would assume high orphan rate. Even our new 60 second drift is creating a bit higher orphan rate, but nothing absurd.[/quote]

Thank you presstab, I’ve just opened an issue on ppcoin’s github. Hopefully this will be fixed in the next version release: https://github.com/ppcoin/ppcoin/issues/82

[Thireus]

Changing the nMaxClockDrift variable requires additional changes. Previous blocks that were accepted within this window would be rejected if they are outside the newly chosen window.

What would you suggest presstab to continue accepting the previous blocks? Manually set a timestamp to state before this date nMaxClockDrift = 2h, after this date nMaxClockDrift = 60sec?

[emeth]

How is sigmike’s answer invalid?

@sigmike

[quote=“mhps, post:9, topic:2189”][quote=“sigmike, post:7, topic:2189”]This timestamp is added to other data from your transaction and you produce a 256 bits hash with that. And you compare this big number with (current target * coin age). If your hash is below this adjusted target, your kernel is valid to make a PoS block.

Since the network has a tolerance of two hours of time stamp error, does it mean one can try 14400 different time stamps per second?[/quote]

Yes. There are other limits involved but you can try more timestamps per second. The client already tries some previous timestamps if you missed them.

But if you try the next 14400 timestamps at time t, then at time t+1 you’ll try 14399 timestamps you’ve already tried, and only try 1 new. So you still try only 1 new timestamp per second.

If you do that it may still be a little easier to find a block if the difficulty changes a lot (because you’ll try more timestamps when the difficulty is low). But it’s probably not significant. And you wouldn’t get more reward, you’d only a part of it earlier.[/quote]

[presstab]

[quote=“Thireus, post:11, topic:3338”]Changing the nMaxClockDrift variable requires additional changes. Previous blocks that were accepted within this window would be rejected if they are outside the newly chosen window.

What would you suggest presstab to continue accepting the previous blocks? Manually set a timestamp to state before this date nMaxClockDrift = 2h, after this date nMaxClockDrift = 60sec?[/quote]

You just say if timestamp is less than x use drift 1 else drift 2.

[presstab]

[quote=“emeth, post:12, topic:3338”]How is sigmike’s answer invalid?

@sigmike

[quote=“mhps, post:9, topic:2189”][quote=“sigmike, post:7, topic:2189”]This timestamp is added to other data from your transaction and you produce a 256 bits hash with that. And you compare this big number with (current target * coin age). If your hash is below this adjusted target, your kernel is valid to make a PoS block.

Since the network has a tolerance of two hours of time stamp error, does it mean one can try 14400 different time stamps per second?[/quote]

Yes. There are other limits involved but you can try more timestamps per second. The client already tries some previous timestamps if you missed them.

But if you try the next 14400 timestamps at time t, then at time t+1 you’ll try 14399 timestamps you’ve already tried, and only try 1 new. So you still try only 1 new timestamp per second.

If you do that it may still be a little easier to find a block if the difficulty changes a lot (because you’ll try more timestamps when the difficulty is low). But it’s probably not significant. And you wouldn’t get more reward, you’d only a part of it earlier.[/quote][/quote]

Its not invalid, it just doesn’t really address any of the issues.

The biggest issue is difficulty adjustment that happens from submitting blocks in the future, and he seems to not consider this at all.

I have the power to stake into the future, lower the difficulty significantly, and have thousands of more chances to stake at the given moment in time than you do. Given enough stakes coming in with this code, it will make it much easier to perform a double spend or another attack on the chain.

All it really takes is for someone like me to create a wallet with the code, release it and say “hey everyone use this and you will stake much faster”, and the network gets really screwed up once enough jump on the new wallet.

[kactech]

Peercoin’s minting maybe isn’t optimal because it’s built upon PoW mining code and previous protocol, I’ll make a PR and we’ll discuss it. New designs introduce new holes so it’s safer to base on tested code and optimize it later.
—edit—
@ Interview with Presstab about PoS Coin Vulnerabilities | Bitcoinist.com

Each second that goes by, the code will then hash the same 59 hashes that it did one second ago, adding one new hash to the end that reflects the time changing. This becomes a burden on the CPU, and there is no reason to hash the same exact hash over and over.

That's false. ---!edit---

Author of article mixes coins w/ different block interval targets, diff adjusting algos and other PoS parameters(2h drift, 10min target != 2h drift, 1min target) so it’s hard to say if his study and conclusions match our network, ofc it worths exploring.

[thehuntergames]

Looking at function CBlock* CreateNewBlock once more, if the line
if (nSearchTime > nLastCoinStakeSearchTime)
really means that newer block has to be later than the previous, it could mean that tweaked nodes may prevent another blocks from happening.

example: lets say you know (with the help of findstakejs) that one output of mine wil be tomorrow at 11:02 AM at a min difficulty of 16.1

Unless the diff is higher than 16.1 tomorrow I will mint that stake, no matter how many ohers have tweaked nodes/minted or not.
That is because no hashes of previous blocks are needed to calculate my stake.
The idea that a tweaked node may effect the diff dropping only assures my future mint.
That said, if a tweaked node were to be able to stake at 11:15 while the actual time is 10:03, will this prevent me from getting my stake accepted by the network by the time my stake is found?

[kactech]

[member=30004]thehuntergames[/member]
Example: you’ll be able to mint

peercoin/peercoin/blob/master/src/main.cpp

// Check timestamp against prev if (GetBlockTime() <= pindexPrev->GetMedianTimePast() || GetBlockTime() + nMaxClockDrift < pindexPrev->GetBlockTime()) return error("AcceptBlock() : block's timestamp is too early");

Your stake(/block) time have to be higher than median of past 11 blocks.

[thehuntergames]

thx
I’ll consider the myth busted. Maybe the theory was based on NXT code? dunno, it has no hold on the inner workinks of ppc.

However, I do think someone, preferably a copywriter, should rewrite that chapter what pillow initially wrote. I dont find it clear and concise IMHO.

[Thireus]

@thehuntergames

I’ll consider the myth busted.

Wait…what? What do you mean the myth is busted? The myth is no longer a myth but a fact!

[thehuntergames]

The notion that it is 11,900% more likely to hit a hash is BS.

Actually the time when you can stake are predefined. Just play with findstakejs and see for yourself. It is just up to you to start up your wallet when that opportunaty comes along.

It the diff drops just because of a number of tweaked nodes only helps to find more stakes.

There is a post that details ‘How findstake is determined’ and the take away is nothing matters, as long as people mint on time. It does not matter that more or less stakes are found by others.
As it does not need hashes from the previous block.
It is like playing blackjack iso poker, it is between you and the dealer. How other players play wont effect the result