Pages:
Author

Topic: 💸  DigiCube  🔷  NOW ON RAWX (NEW MCXNOW)  💸  EARN 50K CUBE/WEEK WITH TWITTER! - page 70. (Read 460478 times)

legendary
Activity: 1778
Merit: 1000
Basically, you need to stake above the maximum reward possible to get a positive stake, which will be squished to the maximum reward. This system is designed to reward large or long holders and punish those trying to stake fast and sell
Then it is good.
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
So how long do I need to keep the wallet locked with 2.2M blocks?


Depends on stake rate. If you get a 500% rate, you need a lot less time than if you were going to hit a 1%

It's impossible to predict what you will receive until time of stake. Therefore, it might be best to just use one giant input if that amount can make you stake higher than the maximum reward per block
full member
Activity: 213
Merit: 100
The idea sound good but how will that bring new investors.?




member
Activity: 90
Merit: 10
So how long do I need to keep the wallet locked with 2.2M blocks?
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
Basically, you need to stake above the maximum reward possible to get a positive stake, which will be squished to the maximum reward. This system is designed to reward large or long holders and punish those trying to stake fast and sell
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
That said.. changing to a straight coinage-styled system is not hard to do, but please do not take this decision lightly as it requires a LOT of time and work to get all sites and wallets updated and a lot fewer coins will be burned
What are people complaining about?

Needing a much higher coinage than expected. I did not explain it clearly earlier
legendary
Activity: 1778
Merit: 1000
That said.. changing to a straight coinage-styled system is not hard to do, but please do not take this decision lightly as it requires a LOT of time and work to get all sites and wallets updated and a lot fewer coins will be burned
What are people complaining about?
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
That said.. changing to a straight coinage-styled system is not hard to do, but please do not take this decision lightly as it requires a LOT of time and work to get all sites and wallets updated and a lot fewer coins will be burned
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
Ok, I need to do some clarifying here. We are going to break down a few lines from this function so I can explain it as clearly as possible
Original:
Code:
   int64 nMinReward = nHeight * .0011;

Last fork:
Code:
   nMinReward = nMinReward * 10;

This fork:
Code:
   nMinReward = nMinReward * 10;


my bad, i didn't notice another "nMinReward = nMinReward * 10;" in previous IF block.

this makes things even worse, positive stakes may occur only for coinage of 8.035...4017.67 * blockheight
depending on lottery outcome

practical result is all stakes negative from block 1mil up to now, check Annualized Stake Rate
http://www.presstab.pw/phpexplorer/CUBE/

Correct, I gave a bad explanation of the system. I should have gone in-depth earlier
member
Activity: 90
Merit: 10
Hmm.   Reblocked my coins yesterday at 15:10 into 2.2million blocks and turned off staking.   Just got in, turned on staking (it's 17:00 here)  and BOOOM two blocks staked instantly for -229167, and -229149 cube!   Staking is turned back off as I've lost almost 1/2 million already.   Why did this negative stake with blocks of 2.2million?
legendary
Activity: 2548
Merit: 1054
CPU Web Mining 🕸️ on webmining.io
Ok, I need to do some clarifying here. We are going to break down a few lines from this function so I can explain it as clearly as possible


Code:
int64 GetProofOfStakeReward(int64 nCoinAge, int nHeight)
{
    static int64 nRewardCoinYear = 2000 * CENT;
    int64 nVariableStakeRate = ((nCoinAge % 500) + 1) * CENT;
    int64 nSubsidy = nRewardCoinYear * nCoinAge * 33 / (365 * 33 + 8);
    int64 nMinReward = nHeight * .0011;
    int64 nMaxReward = nHeight * .01;
    int64 nSquish = nSubsidy / 1000000;
    if (nHeight > 500000) {
nSubsidy = nRewardCoinYear * nCoinAge * 33 / (365 * 33 + 8);
if (nSquish > nMaxReward) {
nSubsidy = nMaxReward * COIN;
}
if (nSquish < nMinReward) {
nSubsidy = 1 * COIN;
}
}
    if (nHeight > 620000) {
nSubsidy = nRewardCoinYear * nCoinAge * 33 / (365 * 33 + 8);
nSquish = nSubsidy / 1000000;
nMinReward = nMinReward * 10;
nMaxReward = nMaxReward * 10;
if (nSquish > nMaxReward) {
nSubsidy = nMaxReward * COIN;
}
if (nSquish < nMinReward) {
nSubsidy = 1 * COIN;
}
}
if (nHeight > 1000000) {
nSubsidy = nVariableStakeRate * nCoinAge * 33 / (365 * 33 + 8);
nSquish = nSubsidy / 1000000;
nMinReward = nMinReward * 10;
if (nSquish > nMaxReward) {
nSubsidy = nMaxReward * COIN;
}
if (nSquish < nMinReward) {
nSubsidy = (nCoinAge - (nCoinAge * 1.1)) * COIN;
}
}
    return nSubsidy;
}


The part that matters is this:


Code:
if (nSquish < nMinReward) {
nSubsidy = (nCoinAge - (nCoinAge * 1.1)) * COIN;
}


Follow nMinReward back, so we know the value needed to not hit this section:


Original:
Code:
    int64 nMinReward = nHeight * .0011;

Last fork:
Code:
    nMinReward = nMinReward * 10;

This fork:
Code:
    nMinReward = nMinReward * 10;


So now, nMinReward is (nHeight * .11), meaning that in order to stake for a positive amount, the actual stake reward must be higher than 11% of the block number in order to receive a positive stake. The number needed to maintain this amount will be different, based on that input's stake rate. This means that stakes will be hitting the maximum reward

If this system proves to not be as easy to use as intended, we can fork to make it a bit easier later and use a straight coinage-dependent formula. The way this is now designed is made to burn coins as much as possible (at least for a little while so supply gets to a more manageable amount), while still providing incentive (or a chance for incentive). If there is a large percentage of people that prefer a straight coinage-style formula, we can update to that if we have to. However, changing now means inflation will continue, although not as extreme as before

Sorry for the confusion, I could have explained this a little better earlier. It may have been an oversight on my part not to switch formulas right away and keep the new formula based on the old stake rate, but it is what it is. We have a lot of wallets and nodes that need updating if we decide to switch, so please do not take this decision opportunity lightly because it is a lot of work getting everyone everywhere to update
newbie
Activity: 78
Merit: 0
Is it just me or the system is very slow right now? 2 of 6 confirmations in 2 hours
legendary
Activity: 966
Merit: 1000
In holiday we trust
To avoid getting minus stake make sure you have your blocks higher than :









newbie
Activity: 78
Merit: 0
Then that is not the correct address

what about this one sir?
Transaction ID: Payment to self that is still unconfirmed for 1 day. Using the address that I posted..
719acc9136c202ebfcc99c1ba49661584cedcc95facf94f1c5905785a82c0b28
legendary
Activity: 1204
Merit: 1000
to your stations, man the pineapples!!!
No, all of my inputs that staked negative were over 2 million. Well over 2 million

Look again please

have you moved any coins after this stake ? if not do a screenshot of the minting tab

Have not moved anything yet, all I have done is lock my wallet so I dont lose more

Screenshotting the minting tab, which is a mess is no help to anyone..

look at the stake input column on this block: http://www.presstab.pw/phpexplorer/CUBE/block.php?height=1000047

2,500,000 exactly

Minted: -250,888.30, 10% of the input size


It appears to me that the coinage is calculated after minimum stake age is deducted.
so those coins were only 4'36" old

but I cant work out how to get your particular outcome

 int dayWeight = (min((GetAdjustedTime() - nTime) + timeOffset, (int64)STAKE_MAX_AGE) - nStakeMinAge) / 86400;

 uint64 coinAge = max(txOut.nValue * nDayWeight / COIN, (int64)0);

newbie
Activity: 63
Merit: 0
I compile my own wallet, my stakes dont split unless they reach my predefined threshold.

Obviously the cube wallet doesnt like that and Ive dropped over a million even though I followed the staking guide.

Oh well, Im not into manually recombining and I'll have to wear that one. Expensive lesson though. So be it.

hero member
Activity: 1638
Merit: 507
The snake which cannot cast its skin has to die
it helps to see the minting tab, as it shows how the inputs were split after the stake with their transaction IDs.
newbie
Activity: 63
Merit: 0
No, all of my inputs that staked negative were over 2 million. Well over 2 million

Look again please

have you moved any coins after this stake ? if not do a screenshot of the minting tab

Have not moved anything yet, all I have done is lock my wallet so I dont lose more

Screenshotting the minting tab, which is a mess is no help to anyone..

look at the stake input column on this block: http://www.presstab.pw/phpexplorer/CUBE/block.php?height=1000047

2,500,000 exactly

Minted: -250,888.30, 10% of the input size
hero member
Activity: 1638
Merit: 507
The snake which cannot cast its skin has to die
full member
Activity: 203
Merit: 100
Pages:
Jump to: