Author

Topic: [HYP] HyperStake | Generous Reward Staking | Advanced Staking Controls & Wallet - page 342. (Read 679350 times)

legendary
Activity: 1330
Merit: 1000
Blockchain Developer



That was 9.09 days (786150 seconds) from block of transaction to stake. There is a known error that coin control reports your system time when in fact all that matters for staking purposes is the network time.

Hope this helps clarify.
hero member
Activity: 630
Merit: 500
full member
Activity: 168
Merit: 100
Wallet version 1.03 working fine and synched immediately. New look is great, awesome logo.
-Though my 25000 HYP (TRK) (from copied wallet.dat file) still shows as unconfirmed. Always has been that way.

It might be from after the fork. Try typing your wallet address into the HYP block explorer and seeing if anything shows up. 

 Address shows 'not seen on the network'. Hmm. Oh, well. Thank-you for the suggestion.
full member
Activity: 457
Merit: 103
v1.0.3 might be mandatory.

i was getting 0 active connections on v1.0.2 and with v1.0.3 i have 5 active connections.
v1.0.3 adds a DNS seed so it is much easier to connect with peers. If you are having problems connecting to peers with v1.0.2 I would suggest either deleting peers.dat or updating versions, or both.
all seem to be good with v103 so far.
i am now waiting to see if staking start for me as i combined my coins into 1500+ blocks on July 12th.

let see what happens now.

update (edit):
weight is 19
network weight is 3733
expected time to earn reward is 4 hours(it just went down from 6 to 4 with in the last few seconds).
rewards are now coming in.
sweet.
legendary
Activity: 1330
Merit: 1000
Blockchain Developer
HYP start staking again now only after 7 days Huh? i thought it was 9 days or i missed something  Huh

You staked in 7 days? Please link me to the txid.
hero member
Activity: 630
Merit: 500
HYP start staking again now only after 7 days Huh? i thought it was 9 days or i missed something  Huh
legendary
Activity: 1330
Merit: 1000
Blockchain Developer
Wallet version 1.03 working fine and synched immediately. New look is great, awesome logo.
-Though my 25000 HYP (TRK) (from copied wallet.dat file) still shows as unconfirmed. Always has been that way.

It might be from after the fork. Try typing your wallet address into the HYP block explorer and seeing if anything shows up. 
full member
Activity: 168
Merit: 100
Wallet version 1.03 working fine and synched immediately. New look is great, awesome logo.
-Though my 25000 HYP (TRK) (from copied wallet.dat file) still shows as unconfirmed. Always has been that way.
legendary
Activity: 1372
Merit: 1022
Anarchy is not chaos.
the price has came back well on coinswap.people must be kicking themselves for selling in the 250-300 range Grin

Well I certainly won't kick 'em for it. Managed to pick up a fair amount for a broke man because of it Cheesy
hero member
Activity: 658
Merit: 503
Monero Core Team
v1.0.3 might be mandatory.

i was getting 0 active connections on v1.0.2 and with v1.0.3 i have 5 active connections.
v1.0.3 adds a DNS seed so it is much easier to connect with peers. If you are having problems connecting to peers with v1.0.2 I would suggest either deleting peers.dat or updating versions, or both.
I see you already added the DNS Seed to the features matrix. Smiley
legendary
Activity: 1330
Merit: 1000
Blockchain Developer
will you be adding the feature where your coins are split into the appropriate block amounts for staking? or is that something I just wished for in my head when trying to do it manually

foxy is lazy.

I have been messing around with this and it is a bit harder than it sounds. Right now I have found out that sendmany isn't working properly, but if I do understand the code correctly it sends multiple transactions on one transaction id - this could be ported over to split a block in one transaction.  Without being able to split it all on one txid, it would mean having the code reselect which block to split each time after it splits, which gets a bit more complicated.

So this is something I have worked on, but it is not my highest priority at the moment.
sr. member
Activity: 476
Merit: 250
will you be adding the feature where your coins are split into the appropriate block amounts for staking? or is that something I just wished for in my head when trying to do it manually

foxy is lazy.
full member
Activity: 457
Merit: 103
v1.0.3 might be mandatory.

i was getting 0 active connections on v1.0.2 and with v1.0.3 i have 5 active connections.
v1.0.3 adds a DNS seed so it is much easier to connect with peers. If you are having problems connecting to peers with v1.0.2 I would suggest either deleting peers.dat or updating versions, or both.
all seem to be good with v103 so far.
i am now waiting to see if staking start for me as i combined my coins into 1500+ blocks on July 12th.

let see what happens now.

update (edit):
weight is 19
network weight is 3733
expected time to earn reward is 4 hours(it just went down from 6 to 4 with in the last few seconds).
legendary
Activity: 1330
Merit: 1000
Blockchain Developer
v1.0.3 might be mandatory.

i was getting 0 active connections on v1.0.2 and with v1.0.3 i have 5 active connections.
v1.0.3 adds a DNS seed so it is much easier to connect with peers. If you are having problems connecting to peers with v1.0.2 I would suggest either deleting peers.dat or updating versions, or both.
full member
Activity: 457
Merit: 103
v1.0.3 might be mandatory.

i was getting 0 active connections on v1.0.2 and with v1.0.3 i have (edit)8 active connections.
legendary
Activity: 1330
Merit: 1000
Blockchain Developer
AN UPDATE CONCERNING UPCOMING FORK AND INFLATION
Hello everyone, I have been working hard running numbers and testing code to come up with a long term solution to inflation. As it sits now, HyperStake will not be inflationary in the long term.  Because there is a maximum reward, HyperStake is only allowed to add a fixed amount of coins to the money supply everyday.  As the money supply grows, the maximum amount added remains constant and therefore becomes less and less % of the money supply every day.

Although the long run will not be inflationary, the short run can be.  The focus of my attention has been to slow down the short run's inflation and have a smoother transition into the long run. My thoughts have been to cut the maximum subsidy down to 500, which would have little if any impact on most of us because a block of 1600 could still get full reward if staked on day 9.  I have also desired to increase the block speed to slow down the amount of coins added to the supply per day.

So far in my testing, changing the maximum has proved quite easy and the chain accepts it. Changing the block speed has been a bit more difficult and requires modification to elements in kernel modifier, which is tricky business. For this reason I am going to need more time to fully test these changes.

NEW WALLET RELEASE v1.0.3 - NOT MANDATORY
Since the fork might take a week or two more to properly test everything, I am going to release the latest version of the wallet now... I just can't keep these fancy new logos made by Kussaka and Zeewolf to myself anymore.  The wallet also adds a checkwallet and repairwallet button that rescans the wallet for orphans and bad transactions and clears them. It also now displays the network stake weight when you hover over the minting icon, even if you are not minting. There is a new command "getmoneysupply" that allows you to look up the money supply of a specific block in the debug window.

https://github.com/presstab/HyperStake/releases/tag/v1.0.3



legendary
Activity: 1330
Merit: 1000
Blockchain Developer
HYP is coin of the day on Coin-swap, no buy fees today. Best time to buy...

Awesome! Coin-swap has been a great tool for HyperStake so far, and the team is always quick to respond to any problems on #coin-swap.
legendary
Activity: 1330
Merit: 1000
Blockchain Developer
Hi presstab,

I think I found a display issue with the Staking: I bought & withdrew HYP 11.7. 6:22h UTC (time when the transaction was done, which is the time used for display in the wallet). So they appear ripe now, and the wallet is displaying that it would stake any second now for about a day, incl. displaying a weight in coin control.
However, on 11.7. and 12.7., blocks were slooooow and the transactions were only included in a block on 12.7. in the afternoon.
Since blocks are again slow right now as consequence of being slow 9 days ago, I would have expected them to already stake.
So, now I assume that for staking itself, the timestamp of the block will be used, not the timestamp of the transaction.
In a way this is good, because the transaction timestamp might be faked, but perhaps the GUI should take this into consideration and not suggest them being ripe already?

Kind regards
Mike


It actually does use the transaction time rather than the block time. The question I have and am not exactly sure at the moment is whether the transaction time defaults as the block time.

Here is the timeweight code:
Code:
int64 nTimeWeight = min((int64)nTimeTx - txPrev.nTime, (int64)nStakeMaxAge) - nStakeMinAge;
    CBigNum bnCoinDayWeight = CBigNum(nValueIn) * nTimeWeight / COIN / (24 * 60 * 60);

Be mindful that there is still a factor of luck involved in the process. You are trying to create a hash that is larger than the kernel hash, and the more coin weight you have the more likely it will be to solve the problem in a timely manner. Just yesterday a member had a block of 7 stake after 20 days.
full member
Activity: 158
Merit: 100
Hi presstab,

I think I found a display issue with the Staking: I bought & withdrew HYP 11.7. 6:22h UTC (time when the transaction was done, which is the time used for display in the wallet). So they appear ripe now, and the wallet is displaying that it would stake any second now for about a day, incl. displaying a weight in coin control.
However, on 11.7. and 12.7., blocks were slooooow and the transactions were only included in a block on 12.7. in the afternoon.
Since blocks are again slow right now as consequence of being slow 9 days ago, I would have expected them to already stake.
So, now I assume that for staking itself, the timestamp of the block will be used, not the timestamp of the transaction.
In a way this is good, because the transaction timestamp might be faked, but perhaps the GUI should take this into consideration and not suggest them being ripe already?

Kind regards
Mike
Jump to: