Timedrift exploit on PoS coins to increase minting probability

[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

[presstab]

[quote=“kac-, post:15, topic:3338”]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.[/quote]

True that a ten minute block target is not quite as bad. But this is not a reason to excuse it as a myth… Plain and simple, give me enough weight and your difficulty will be ruined. Maybe PPC’s days of being aggressive on security are over? I am not sure. Good luck to you guys.

[kactech]

@presstab

But this is not a reason to excuse it as a myth…

Quote please.

[presstab]

@kac-

[quote=“presstab, post:21, topic:3338”]But this is not a reason to excuse it as a myth…

Quote please.[/quote]

@thehuntergames

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.

[kactech]

Maybe thehuntergames was talking about this [quote=“thehuntergames, post:16, topic:3338”]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?[/quote]

I said that it worths exploring, simulation maybe.
[member=30004]thehuntergames[/member] have you ported diff calculation code to JS?

---

Edit:
Valid scenario is: everyone is minting +2h ahead, in case of fork there is high probability that owner of orphaned block won’t be able to mint once again on a main chain.
That would allow an attacker to exclude some minters = keep diff lower. Condition: lot of minters use modified „future-mint” client.

[presstab]

[quote=“thehuntergames, post:16, topic:3338”]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?[/quote]

I don’t think you are correct, feel free to correct me if I am wrong with my reading of the code.

CreateNewBlock() is triggered by BitcoinMiner().
Initializes with your adjusted time:

static int64 nLastCoinStakeSearchTime = GetAdjustedTime();

nSearchTime is initialized as your txtime for this new block

int64 nSearchTime = txCoinStake.nTime;

You then use checkKernalCoinStake() to find a successful PoS hash
and nLastCoinStakeSearchTime is set to your nSearchTime

nLastCoinStakeSearchTime = nSearchTime;

You continue through the rest of the createblock process because you have successfully produced a stake hash that meets the target. You then exit createblock with your new block. All variables are reinitialized upon restarting the createblock process.

A) I don’t see anywhere that nLastCoinStakeSearchTime is assigned to your submitted tx time, so if you submitted a block way into the future, why would it have that value stored somewhere?
B) The function is reset upon exit
C) This is node specific code, not something that is sent to peers

Am I missing something in my reading of the code, it does get complicated quick, I will be the first to admit that.

I know that it is not uncommon at all for PoS blocks to come in out of chronological order. PPC would be less common because of the larger target spacing, but that doesn’t mean the code forbids it.

[kactech]

@presstab

All variables are reinitialized upon restarting the createblock process.

Almost.

static int64 nLastCoinStakeSearchTime = GetAdjustedTime();

static modifier makes this variable initialized only once, it’s like:

if( nLastCoinStakeSearchTime == 0 ){ nLastCoinStakeSearchTime = GetAdjustedTime(); }

—Edit—
Yep, it reffers to local node minting only, it counters your note about redundant hashing.

[presstab]

Hmm alright so that would mean that it also survives the exit of the function too?

Also, this would only be about redundant hashing, not the ability to produce a stake at time value +2hours and then stake again at time value +5 minutes correct?

[kactech]

Hmm alright so that would mean that it also survives the exit of the function too?

Yep, it's like declared outside of function but visible only in enclosing func.

Also, this would only be about redundant hashing, not the ability to produce a stake at time value +2hours and then stake again at time value +5 minutes correct?

+2h yes +5min idk, how you came to this?

[presstab]

[quote=“kac-, post:28, topic:3338”]

Hmm alright so that would mean that it also survives the exit of the function too?

Yep, it’s like declared outside of function but visible only in enclosing func.

Also, this would only be about redundant hashing, not the ability to produce a stake at time value +2hours and then stake again at time value +5 minutes correct?

+2h yes +5min idk, how you came to this?[/quote]

The conclusion that I am trying to draw is that there is:

[quote=“thehuntergames, post:16, topic:3338”]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.[/quote]

is not the case. This is never assigning the time of the transaction you submit to the network against the next block you create. It is comparing what time you last did a hashing session. Or do you think I am missing something?

[ppcman]

[quote=“Thireus, post:1, topic:3338”]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.
[…]

Any thoughts?[/quote]

Peercoin also has a 520 block confirmation for new blocks, with a blocktime of 10 minutes. It takes 30 days just to earn coinstake.

Keep that in mind when talking about other PoS coins who have ridiculously low block times or block confirmations before a block is considered valid.

It takes a lot longer than 2 hours for 520 block confirmations. We’re talking 3 or 4 days for a newly minted block to fully confirm and be accepted.

I thoroughly enjoy how everyone (not peercointalk people) like to prove how Peercoin’s technology can’t work, but it still works, and works well.

A request:

Can we stop with negative sounding subject lines that are alarmist in nature?

timedrift exploit on PoS coins to increase minting probability

Could have been better written as:

timedrift with PoS coins and minting probability

There is no confirmed exploit with Peercoin. There is no cause for alarm here.

The only thing I see is bad coin devs who fork Peercoin without understanding how the technology works by making a few simple changes, like dropping block confirmations to 6, or stake earned after an hour, or block times of 30 seconds.

Did anyone do the math when you see a block time of 30 seconds for XYZ coin after 3 or 4 years? Any idea how huge the blockchain would be? So many junk coins on the market, and when things go wrong they love to blame PoS.

PoS done right works well.

PoS done wrong, doesn’t. That’s not alarming, that’s common sense.

[presstab]

[quote=“ppcman, post:30, topic:3338”][quote=“Thireus, post:1, topic:3338”]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.
[…]

Any thoughts?[/quote]

Peercoin also has a 520 block confirmation, with a blocktime of 10 minutes. It takes 30 days just to earn stake.

Keep that in mind when talking about other PoS coins who have ridiculously low block times or block confirmations before a block is considered valid.

It takes a lot longer than 2 hours for 520 block confirmations. We’re talking 3 or 4 days for a block to fully confirm.

I thoroughly enjoy how everyone (not peercointalk people) like to prove how Peercoin’s technology can’t work, but it still works, and works well. :)[/quote]

I am not trying to prove that peercoin doesnt work, I am a long time PoS fan. I am trying to have a conversation with people that know quite a bit about ppc code, to confirm and explore this area. It seems like a major flaw, which is especially exploitable in PPC clones with narrower params. Peercoin is not perfect, it never has been and that is why it is on protocol 4 now instead of remaining on protocol 1 for PoS blocks. I am sure there will be more changes in the future as well. Discussion about improving it should be encourage not discouraged.

You do bring another variable to the conversation though and that is the maturity.