Timedrift exploit on PoS coins to increase minting probability

[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.

Quote please.

Quote please.[/quote]

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.

[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.

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.

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?

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=“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?

[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. :slight_smile:

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.

[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.

I am not trying to prove that peercoin doesnt work, I am a long time PoS fan.[/quote]

You’re on peercointalk. I wasn’t referring to you.

I would suggest this phrase re-written to be more accurate.

It seems like a flaw that doesn’t affect PPC, but could effect other PPC clones with narrower parms

…to Sunny King’s defense, it’s a flaw that could exist when Peercoin is redesigned in a clone coin fork in a way that doesn’t work the same way Peercoin was designed.

Peercoin is exempt from this problem because of the maturity as you stated and I brought up. Other coins that fork peercoin and start making changes to its code need to understand why the “parms” are what they are in Peercoin. They’re carefully thought out and decided before Peercoin launched.

Peercoin isn’t written to be idiot proof (industry term) for new coin creation on forked github projects. If some one wants to use the code and make their own forked coin, they need to understand how and why Peercoin works the way it does. Not what file to edit, to change the “parms” and that’s it.

Sunny did leave a comment in the code that is very interesting (that I bet a lot of PoS coin devs didn’t read or if they did, did not understand)

// The following split & combine thresholds are important to security
// Should not be adjusted if you don't understand the consequences

http://www.peercointalk.org/index.php?topic=2058.0

That’s one example. Not necessarily about what we’re talking about here. But it’s an example how some newbie coin devs just change “parms” numbers, work on a pretty looking gui wallet, and release a forked clone that is a bad implementation of PoS.

That being said, it doesn’t fix the fact that you can lower the difficulty and overshoot target block creation, which does in fact apply to PPC. The maturity times would simply make a double spend much more difficulty, but doesn’t really prevent the difficulty and block creation from getting out of whack.

re: difficulty and block creation

Now you know why Peercoin has checkpointing. It also had to wait for enough coins to be distributed before checkpointing is going to be removed and for the coin to mature. This year, we’ll be 3 years of the PPC blockchain and wide distribution.

Some coins only do hard-coded checkpointing, or they turn it off. A lot of coins don’t monitor their chains looking for trouble. Sunny King can remotely issue checkpoints without updating the code signed by his private key if something goes wrong.

There is a lot at work here, many moving parts.

We’ve very lucky to have the coindev that we have. PPC is a very strong coin. So any “timedrift exploits” happening on young, junior coins shouldn’t be grouped into the same category as Peercoin.

re: difficulty and block creation

Now you know why Peercoin has checkpointing. It also had to wait for enough coins to be distributed before checkpointing is going to be removed and for the coin to mature. This year, we’ll be 3 years of the PPC blockchain and wide distribution.

Some coins only do hard-coded checkpointing, or they turn it off. A lot of coins don’t monitor their chains looking for trouble. Sunny King can remotely issue checkpoints without updating the code signed by his private key if something goes wrong.

There is a lot at work here, many moving parts.

We’ve very lucky to have the coindev that we have. PPC is a very strong coin. So any “timedrift exploits” happening on young, junior coins shouldn’t be grouped into the same category as Peercoin.[/quote]

Adding blocks into the chain within the timedrift parameters is completely according to protocol and does in fact screw up difficulty and therefore creation.
I understand the concept of checkpoint server, but I don’t think it really is a strong selling point as a solution to this problem because:
A) it requires constant monitoring of the chain and trust that someone is watching 24 hours a day
B) these blocks are according to protocol so why would you try to force them out of the chain? It would require the checkpoint server running a more narrow timedrift parameter, when the rest of nodes would be running 2 hours. I guess that is an ugly way to change protocol instead of actually putting it into the code.
C) PPC is comparably vulnerable to the difficulty as most other “more mature coins” (as you phrase it). 10 minute target with 120 minute futurehash ability 1/12. Compared to HyperStake for example that had 1.5 minute target with 15 minute drift. 1/10.

I ended up changing HYP to run with 60 second and it works great. I guess here is the primary question. If this can screw up difficulty and the target of the coin, then why are you so anxious to keep it? It is not hard at all to reign in timedrift in the next protocol change. What are the primary benefits that PPC has with 2 hours, that BLK does not have with 15 seconds?? Is it a good enough reason to have to hire a night watchman on the checkpoint server that is ready to manually create an alternate illegitimate chain and force all the nodes on to it? It seems like a super whacky idea to be honest. Trust in a person rather than the protocol. So what is this overwhelming benefit that makes it worth it?

Edit - also to be clear. I think peercoin is awesome. I just don’t really love having trust in a person rather than just patching a few things. I would love to see peercoin come out with a newer protocol that makes it even safer and more decentralized.

So now we’re down to seconds? How about internet denial of service attacks? Fibre optic cables cut in certain parts of the internet? BGP routing, ISP outages and other issues.

2 hours is a window to allow the internet to heal and re-route during problematic network outages. It’s a feature, not a limitation.

15 seconds might be a good number for a healthy internet, during healthy times. But during times of DDoS and other outages, 15 seconds is irresponsible and silly and can create it’s own exploitable situations.

I’m not going to spend my entire day going back and forth with you one on one. I saw your 750% stake coin, and giggled. You’re going to have bigger problems than time drift in the long term. So enjoy your experiment.

For now, I’ve hopped in, shared some things with you but my available spare time is short. Hopefully some one else will bite and help figure this out. I don’t have a monopoly of time on my hands at the current time.

You’re assuming that watching the chain has to be a human being. A script can watch the chain, and a human can intervene after being alerted. But this is going to be a moot point soon anyway, because our blockchain is mature enough that these events are no longer a major problem due to distribution and long-term coinage that exists.

I’m talked out for the moment. I’m not a coin dev, and I don’t have a moral responsibility to users of my 750% hyperstake coin in the wild. Best of luck to you.

So now we’re down to seconds? How about internet denial of service attacks? Fibre optic cables cut in certain parts of the internet? BGP routing, ISP outages and other issues.

2 hours is a window to allow the internet to heal and re-route during problematic network outages. It’s a feature, not a limitation.

15 seconds might be a good number for a healthy internet, during healthy times. But during times of DDoS and other outages, 15 seconds is irresponsible and silly and can create it’s own exploitable situations.

I’m not going to spend my entire day going back and forth with you one on one. I saw your 750% stake coin, and giggled. You’re going to have bigger problems than time drift in the long term. So enjoy your experiment.

For now, I’ve hopped in, shared some things with you but my available spare time is short. Hopefully some one else will bite and help figure this out. I don’t have a monopoly of time on my hands at the current time.

You’re assuming that watching the chain has to be a human being. A script can watch the chain, and a human can intervene after being alerted. But this is going to be a moot point soon anyway, because our blockchain is mature enough that these events are no longer a major problem due to distribution and long-term coinage that exists.

I’m talked out for the moment. I’m not a coin dev, and I don’t have a moral responsibility to users of my 750% hyperstake coin in the wild. Best of luck to you.[/quote]

What does the stake rate of HyperStake have to do with peercoin’s timedrift allowance? Looks like I struck a nerve or something?

I don’t see what a ddos attack has to do with anything. I would ask you to elaborate, but it seems like you are too frustrated to respond and probably wouldn’t be able to respond without ad hominem fallacy anyways.