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

[ofeefee]

Is there seriously going to be a true hard-fork with a few hours notice? If so, you are looking at a major train wreck.

Have the services that use/support  Hyperstake been notified? I know I haven't, I only noticed it because it popped up in my reply post list.

Exchanges, explorers, gambling, etc etc?? All these services need time to get setup even after they are notified.

How many users are going to end up on a forked chain because they didn't happen to come to a forum where it has been announced in the last few hours?

I was hoping that this was really going to be a soft fork until I saw this in the code currently in github:

Code:

 if (pfrom->nVersion < 72099)
{
printf("partner %s using an old client %d, disconnecting\n", pfrom->addr.ToString().c_str(), pfrom->nVersion);
pfrom->fDisconnect = true;

I hope it is for testing purposes, and you are not intending to truly block out version 72000 from the new client (In  other words a true hard fork) in the next few hours or even days.

This has to be a misunderstanding on my part. When is the hard-fork actually going to be enforced?

This is also in there...
static const unsigned int FORK_TIME2 = 1423783513; // Fri, 13 Feb 2015 00:00:00 GMT

[presstab]

Presstab, could you describe in two words, pls, the bug in PoS you have discovered, for those who's out of topic, in a non-tech way? To let them have an understanding of what is going on behind the scenes.

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

My original thinking, and the reason I released the beta release, was that if some code tweaker has that advantage, let us even the playing field and give it to everyone. And so I released that code.

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.

With the new HYP code, we got diff as low as 3 i think it was (from the 10+ that it had been before), made 1,975 blocks today (compared to the target of 960), and minted 1.8 million HYP compared to our targeted 960k max.

Hope that makes some sense.  Running the new code on a test network and should have it out soon.

[presstab]

Is there seriously going to be a true hard-fork with a few hours notice? If so, you are looking at a major train wreck.

Have the services that use/support  Hyperstake been notified? I know I haven't, I only noticed it because it popped up in my reply post list.

Exchanges, explorers, gambling, etc etc?? All these services need time to get setup even after they are notified.

How many users are going to end up on a forked chain because they didn't happen to come to a forum where it has been announced in the last few hours?

I was hoping that this was really going to be a soft fork until I saw this in the code currently in github:

Code:

 if (pfrom->nVersion < 72099)
{
printf("partner %s using an old client %d, disconnecting\n", pfrom->addr.ToString().c_str(), pfrom->nVersion);
pfrom->fDisconnect = true;

I hope it is for testing purposes, and you are not intending to truly block out version 72000 from the new client (In  other words a true hard fork) in the next few hours or even days.

This has to be a misunderstanding on my part. When is the hard-fork actually going to be enforced?

No sorry, the official repo is hyperstake/hyperstake, I am running some test code on presstab/hyperstake that includes some extra code that won't be included in the fork. Please ignore it.

I will schedule the fork to happen at (GMT): Fri, 13 Feb 2015 14:00:00 GMT

I wish I felt comfortable giving more time in advanced, but there are more than double the amount of coins being minted than normal.

I will release new binaries tonight and fresh commits to github.com/hyperstake/hyperstake

[ofeefee]

Someone gaming the system apparently.

[presstab]

Is there seriously going to be a true hard-fork with a few hours notice? If so, you are looking at a major train wreck.

Have the services that use/support  Hyperstake been notified? I know I haven't, I only noticed it because it popped up in my reply post list.

Exchanges, explorers, gambling, etc etc?? All these services need time to get setup even after they are notified.

How many users are going to end up on a forked chain because they didn't happen to come to a forum where it has been announced in the last few hours?

Major exchanges have been notified, most of our services have been notified. You were on my list as well, just hadn't got there yet. Trying to do a lot of things at once here.

I was hoping that this was really going to be a soft fork until I saw this in the code currently in github:

Code:

 if (pfrom->nVersion < 72099)
{
printf("partner %s using an old client %d, disconnecting\n", pfrom->addr.ToString().c_str(), pfrom->nVersion);
pfrom->fDisconnect = true;

I hope it is for testing purposes, and you are not intending to truly block out version 72000 from the new client (In  other words a true hard fork) in the next few hours or even days.

This has to be a misunderstanding on my part. When is the hard-fork actually going to be enforced?

This was for my own personal testing. This should be doable via softfork, but I am sure old clients will be likely to get off on their own forks if not updated. Its hard to say for sure. At first we were planning on going all out and getting our whole list of fork items crossed off the list. This is just too much now, and too quick in advanced. I will simply be changing the timedrift code to 60 seconds. No difficulty changes or other changes. Hope this answers your questions, I will get you the updated code as soon as I have it.

[ulfie]

avast ye scurvy scallywags... prepare to be forked!

(can you believe scallywags is in spell check?)

I'm afraid to even google it.
What the *bleep* are scallywags?

Scallywags are what dogs do when you scold them.
 

[presstab]

MANDATORY UPDATE FOR SECURITY MEASURES

https://github.com/hyperstake/HyperStake/releases/tag/v1.1

Forking at 1423836000; // Fri, 13 Feb 2015 14:00:00 GMT
to reign in timedrift to 60 seconds.

Information about attack vectors patched: https://bitcointalk.org/index.php?topic=678849.msg10443393#msg10443393

Note - If you cannot get the autotools to configure properly, then you can also use the code on github.com/presstab/hyperstake which now contains the same code without the autotools update.

[ofeefee]

Does this patch render the stake more obsolete?  Says allows you to hash 10, 5, 3 minutes?  If timedrift is now 1 minute.

[m33]

@presstab so now i download the new wallet and reload data?

which one for windows the one name qt or without?

[ofeefee]

@presstab so now i downloadthe new wallet and reload data?

I loaded it on top of both my stake wallets, looka good.  Backup wallet first as precaution

[ofeefee]

Does this patch render the stake more obsolete?  Says allows you to hash 10, 5, 3 minutes?  If timedrift is now 1 minute.

And in your initial post you mention ppc and nvc with two hour drifts, but hyp and such have 15 minutes.  So you can't hash two hours ahead of time correct?  Only max of 15 minutes.

And do you expect that 60s drift could cause issues?  Like if a computer clock is off a bit?

[ofeefee]

And wow that is an incredible performance improvement, watched it before i upgraded about 20-25% of my cpu, now almost 0, see it bump a bit every now and then.

[iantunc]

Presstab, could you describe in two words, pls, the bug in PoS you have discovered, for those who's out of topic, in a non-tech way? To let them have an understanding of what is going on behind the scenes.

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

My original thinking, and the reason I released the beta release, was that if some code tweaker has that advantage, let us even the playing field and give it to everyone. And so I released that code.

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.

With the new HYP code, we got diff as low as 3 i think it was (from the 10+ that it had been before), made 1,975 blocks today (compared to the target of 960), and minted 1.8 million HYP compared to our targeted 960k max.

Hope that makes some sense.  Running the new code on a test network and should have it out soon.

Thanks for a very clear explanation. It's really a major issue.

[presstab]

Does this patch render the stake more obsolete?  Says allows you to hash 10, 5, 3 minutes?  If timedrift is now 1 minute.

And in your initial post you mention ppc and nvc with two hour drifts, but hyp and such have 15 minutes.  So you can't hash two hours ahead of time correct?  Only max of 15 minutes.

And do you expect that 60s drift could cause issues?  Like if a computer clock is off a bit?

Yes it was only 15 minutes for HYP, and I had only allowed 10 minutes in my build of the wallet. It was still what i would consider catastrophic, and so far our diff spiral has only been fixed by voluntary downgrading of client without the future hashing code. So if a 15 minute drift can do this, imagine a 120 minute drift...

I see that blackcoin and clams both use a 15 second drift. I think 60 seconds is a could compromise between less orphans and more safety.

[almightyruler]

No luck with current github version... same function defined twice?

  CXXLD    hyperstaked
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `FormatFullVersion()':
/var/coins/hyperstake/src/HyperStake-master/src/util.cpp:1325: multiple definition of `FormatFullVersion()'
libbitcoin_util.a(libbitcoin_util_a-clientversion.o):/var/coins/hyperstake/src/HyperStake-master/src/clientversion.cpp:89: first defined here
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `FormatSubVersion(std::string const&, int, std::vector<std::string, std::allocator<std::string> > const&)':
/var/coins/hyperstake/src/HyperStake-master/src/util.cpp:1331: multiple definition of `FormatSubVersion(std::string const&, int, std::vector<std::string, std::allocator<std::string> > const&)'
libbitcoin_util.a(libbitcoin_util_a-clientversion.o):/var/coins/hyperstake/src/HyperStake-master/src/clientversion.cpp:97: first defined here
gmake[1]: *** [hyperstaked] Error 1
gmake[1]: Leaving directory `/var/coins/hyperstake/src/HyperStake-master/src'
gmake: *** [all-recursive] Error 1

[David Latapie]

Try install instruction here (for Linux)
Installation guide

[almightyruler]

Try install instruction here (for Linux)
Installation guide

Thanks, but I've built the HYP daemon before without any issues. It looks like a possible programming error.

A file which appears only in the newer version, clientversion.cpp, seems to dupe define a couple of functions.

Commenting out both FormatFullVersion() and FormatSubVersion() in clientversion.cpp allows the build to complete. The duplicate functions are not quite identical, so I'll let the dev determine which ones should be retained.

edit: just checked github, and the latest commit (a minute ago - good timing!) has deleted these from util.cpp. Will try a build with the update.

[presstab]

Try install instruction here (for Linux)
Installation guide

Thanks, but I've built the HYP daemon before without any issues. It looks like a possible programming error.

A file which appears only in the newer version, clientversion.cpp, seems to dupe define a couple of functions.

Commenting out both FormatFullVersion() and FormatSubVersion() in clientversion.cpp allows the build to complete. The duplicate functions are not quite identical, so I'll let the dev determine which ones should be retained.

edit: just checked github, and the latest commit (a minute ago - good timing!) has deleted these from util.cpp. Will try a build with the update.

Yep, we just recently ported over to autotools and have found that bug. Allejupa got it all updated and it should be working now. I have also been maintaining a non-autotools port at github.com/presstab/hyperstake that you could try.

For anyone wondering if they are on the correct chain, hyp.cryptocoinexplorer.com is on the correct chain, so double check there

[nioc]

I just checked and I am on the same block # so I assume everything is ok there.

Right after checking my wallet said it was out of sync and was synchronizing with the network with 8 blocks remained and then 19 blocks.  After a couple of minutes it now says 18 blocks remaining.


It went down to 17 blocks behind and now is at 21 blocks.  I am still on the same blockcount as hyp.cryptocoinexplorer.com

Edit#2 will this effect staking?

[presstab]

I just checked and I am on the same block # so I assume everything is ok there.

Right after checking my wallet said it was out of sync and was synchronizing with the network with 8 blocks remained and then 19 blocks.  After a couple of minutes it now says 18 blocks remaining.


It went down to 17 blocks behind and now is at 21 blocks.  I am still on the same blockcount as hyp.cryptocoinexplorer.com

Edit#2 will this effect staking?

I think this is the shitty part of this whole "soft fork" route where we still allow connections to other clients. They have gone off on their fork, and we still see them.

This should not affect staking, at least it hasnt for me so far.