[ANN] ** NEW SITE bitgem.pw ** BTG BitGem 0.4.9.ALPHA1 | COLORED COINS | FAUCET

[mineral]

3BTG, your reward stake is  0.00125 %  of 3 BTG = 0.00375  BTG  ...  

0 a.k.a zero

Note: listaccounts does not work as expected...returns wrong value.
getbalance before = getbalance atfer.

not 0.10 BTG , 0.00125 CENT , it is 10,000 times lesser

Good point, but 0 it's zero, if you prefer "0.00000000"

Take a look into PPC or NVC source (mainly kernel.cpp and kernel.h) and then you talk about stake ... At the moment, is better be quiet than to seem an ignorant.

I really wonder how people can recomend to deactivate something they dont know how it work ... amazing.

Sorry, I did no one recommendation. NVC, PPC or PingPongcoin,..., POW and POS are software designs not totems. I am speaking about people, people does not mine/spend resources if get nothing,...Software can sing about unicorns or other creatures. It's only an idea.

This dialog  is useless.

Already all said about calculations. If you has got 1,000 BTGs you has got 1 BTG.

And in the case of 0 stake, which is not the case as explained, do you prefer the 51% attack of the clones ... ?  Have you realized that anyone stake coin have not been 51% attacked? Why will be it eh?

And next month it will be the new stake, so if you are a little pacient it will be worth .

[YukonCoinelius]

ALERT - Stake Mining Broken for small values - DETAILS AND FIX

I have generated a BitGem stake with maximum debug options (see log below), and investigated the situation why stake-mining has been yielding 0 bonus. It's a different issue than what they fixed for Bitbar (although the wallet rounding fix for bitbar might *also* be necessary in BitGem, but first we have to *create* the right stake reward, before worrying about crediting the wallet).  Also note: This issue actually applies to all the stake-mined coins (btg, btb, yac, nvc, ppc, ...) and I am planning to repeat post in a separate topic.

In a nutshell (after *lots* of debug work, all bitgemmer thank-you gifts welcome!):

in main.cpp, GetProofOfStakeReward, the line

Code:

int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

is wrong for small values of nCoinAge (which result when the underlying transaction amounts are small).

When nCoinAge < 366, nSubsidy evaluates to 0 because of integer division truncation.

Because BitGem and BitBar deal mostly with small amounts, nCoinAge will almost always be less than 366, and so the formula yields 0 stake credit almost always (unless you have a very large bitgem transaction amount).


To illustrate, note these lines from the long debug log at end of posting:

coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891

You see “create=0.00” as the computed nSubsidy, when it should be near 0.00887

This is a 3-unit coin that was about 36 days old (3 * 36 = 108 coindays).
Since June-20, Stake Mining Interest rate in Bitgem ranges 1-3% - I believe 3% (0.03) at the current difficulty.
So mathematically, the stake nSubsidy should be  

Code:

108 * 33 / (365 * 33 + 8) * 0.03 = 0.00887

But because all the numbers are internally represented as integers, the integer division truncation occurs.

Specifically:

Code:

 (108 * 33 / (365 * 33 + 8)) = 0

with the integer divide.

Probably the reason this hasn't been noticed on the stake-coins before, is that with other stakecoins the nCoinAge is much bigger because the coin amounts are larger. PPCoin was originally dealing with amounts in the 1000s. So if you have a transaction holding a 1000-coin for a month, you have 1000 * 30 = 30000 coindays, much bigger than 366.

CODE FIX

Fortunately, I think there is an easy code fix here, which is to reorder the calculation like this:

Code:

int64 nSubsidy = nRewardCoinYear * nCoinAge * 33 / (365 * 33 + 8) ;

Now the integer division will not truncate to 0, and because all the values are int64, it should be safe from overflow too.
(Safe even in ppcoin, which could have values for CoinAge like 1M coins for 1000 days = 1 Billion coin days, still fits fine in int64)
This will also give more accurate results in all the stake-coins for large values, which currently are rounding to the nearest multiple of a coin-year.

Because this issue affects all the stake-mined coins, I'm planning to re-post this as it's own topic. But it would be good if we could get it patched in BitGem first/fastest, since it matters more here.

Finally, I'll mention here again this is a pretty major issue affecting all the stake-coins to varying degrees, and my diagnosis and fix will probably save/make everyone some money, either directly or indirectly. So all thank-you gifts welcome:

BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N
or,
BTC: 13xN2MvG9RcvWY92HeMpMFgBbGq9RLW64z
LTC: LKgvPQBp7wWxP57T8YWHY1dVnstBE81FyW
FRC: 19nQm96DNew1Wrm1LG9eNvpkTT2wauryih
(others welcome too, request my addr)


FULL-DETAIL DEBUG LOG OF BITGEM STAKE-MINED BLOCK:

CheckStakeKernelHash() : using modifier 0xc78b730c95ac918f at height=5303 timestamp=2013-05-25 12:12:22 UTC for block from height=3528 timestamp=2013-05-16 14:27:50 UTC
CheckStakeKernelHash() : pass protocol=0.3 modifier=0xc78b730c95ac918f nTimeBlockFrom=1368714470 nTxPrevOffset=81 nTimeTxPrev=1368714470 nPrevout=0 nTimeTx=1371833019 hashProof=00000a7e92270e1d1912e9b109825a5af621e8897b9ab7c42d3722b3601bee48
CreateCoinStake : kernel found
CreateCoinStake : parsed kernel type=1
CreateCoinStake : added kernel type=1
coin age nValueIn=3000000 nTimeDiff=3118549 bnCentSecond=935564700
coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891
CreateCoinStake : fee for coinstake 0.00
CreateNewBlock(): total size 1000
keypool return 5
CPUMiner : proof-of-stake block found a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce
BitcoinMiner:
new block found  
  hash: a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce  
target: 000009e4db000000000000000000000000000000000000000000000000000000
CBlock(hash=a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce, ver=4, hashPrevBlock=389023b31af092d537eaf27360c73fd8318e6cd75e20ddae3ef3be5079decc07, hashMerkleRoot=9f99a622a5fd66fe1eaf26d6e31b37cce3e2b6ccfbd71ee83fcb110b21cb857a, nTime=1371833019, nBits=1e09e4db, nNonce=0, vtx=2, vchBlockSig=30460221009b1fa391f759a94f3ee96ae831b4eb9b2e58309e5181818beb66b03d396f91ae022100807e9dee8a2758e5d0c27f1eaa89ddf35b544732f3ca358e8c320f8882eb40c8)
  Coinbase(hash=009458e775, nTime=1371833019, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 028b2602c006062f503253482f)
    CTxOut(empty)
  Coinstake(hash=d0fbc90cd0, nTime=1371833019, ver=1, vin.size=1, vout.size=3, nLockTime=0)
    CTxIn(COutPoint(8ac47fa04a, 0), scriptSig=30460221009c26337f666328)
    CTxOut(empty)
    CTxOut(nValue=1.50, scriptPubKey=036dedb30ffdcdb3988c4232af8536824d44fd8d8191bbe485d02bca74d1c09246 OP_CHECKSIG)
CTxOut(nValue=1.50, scriptPubKey=036dedb30ffdcdb3988c4232af8536824d44fd8d8191bbe485d02bca74d1c09246 OP_CHECKSIG)
  vMerkleTree: 009458e775 d0fbc90cd0 9f99a622a5
generated 0.00
CheckStakeKernelHash() : using modifier 0xc78b730c95ac918f at height=5303 timestamp=2013-05-25 12:12:22 UTC for block from height=3528 timestamp=2013-05-16 14:27:50 UTC
CheckStakeKernelHash() : check protocol=0.3 modifier=0xc78b730c95ac918f nTimeBlockFrom=1368714470 nTxPrevOffset=81 nTimeTxPrev=1368714470 nPrevout=0 nTimeTx=1371833019 hashProof=00000a7e92270e1d1912e9b109825a5af621e8897b9ab7c42d3722b3601bee48
trying connection 92.206.87.53:7692 lastseen=79.5hrs
GetStakeEntropyBit: nHeight=9867 hashBlock=a2ad30df67f6b37f2f9301bff115a4095e003f57004fb6061c24e6feecef01ce nEntropyBit=0
ComputeNextStakeModifier: prev modifier=0xd895202b9a9a4cda time=2013-06-21 12:04:50 UTC
coin age nValueIn=3000000 nTimeDiff=3118549 bnCentSecond=935564700
coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891
ConnectBlock() : destroy=0.00 nFees=0
connect() failed after select(): No route to host
AddToWallet d0fbc90cd0  new
WalletUpdateSpent found spent coin 3.00nvc 8ac47fa04afe24669bfb17ccc35b0baea55e41203be0b89ab4c8dc8bfbeaba1e
SetBestChain: new best=a2ad30df67f6b37f2f93  height=9867  trust=1178452533  date=06/21/13 16:43:39
ProcessBlock: ACCEPTED

[mineral]

ALERT - Stake Mining Broken for small values - DETAILS AND FIX

I have generated a BitGem stake with maximum debug options (see log below), and investigated the situation why stake-mining has been yielding 0 bonus. It's a different issue than what they fixed for Bitbar (although the wallet rounding fix for bitbar might *also* be necessary in BitGem, but first we have to *create* the right stake reward, before worrying about crediting the wallet).  Also note: This issue actually applies to all the stake-mined coins (btg, btb, yac, nvc, ppc, ...) and I am planning to repeat post in a separate topic.

In a nutshell (after *lots* of debug work, all bitgemmer thank-you gifts welcome!):

in main.cpp, GetProofOfStakeReward, the line

Code:

int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

is wrong for small values of nCoinAge (which result when the underlying transaction amounts are small).

When nCoinAge < 366, nSubsidy evaluates to 0 because of integer division truncation.

Because BitGem and BitBar deal mostly with small amounts, nCoinAge will almost always be less than 366, and so the formula yields 0 stake credit almost always (unless you have a very large bitgem transaction amount).


To illustrate, note these lines from the long debug log at end of posting:

coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891

You see “create=0.00” as the computed nSubsidy, when it should be near 0.00887

This is a 3-unit coin that was about 36 days old (3 * 36 = 108 coindays).
Since June-20, Stake Mining Interest rate in Bitgem ranges 1-3% - I believe 3% (0.03) at the current difficulty.
So mathematically, the stake nSubsidy should be  

Code:

108 * 33 / (365 * 33 + 8) * 0.03 = 0.00887

But because all the numbers are internally represented as integers, the integer division truncation occurs.

Specifically:

Code:

 (108 * 33 / (365 * 33 + 8)) = 0

with the integer divide.
...

FALSE

Code:

108 * 33 / (365 * 33 + 8) * DOUBLE  = DOUBLE 

Because casting conversion, the result will be a DOUBLE, and != 0 because nSubsidy=0.015 * CENT

And, one more time, this month stake reward is not 3%, else  0.015 % , so 0.00015  ,

Code:

108 * 33 / (365 * 33 + 8) *  0.00015  = 0.000044354102713017506015099975109931 

I suppose you understand that printed number in log is not "the real representation"  of float representation in memory (or CPU registry) ...

Well, this debate is good in any case ... no.

[GoldBit89]

3BTG, your reward stake is  0.00125 %  of 3 BTG = 0.00375  BTG  ...  

0 a.k.a zero

Note: listaccounts does not work as expected...returns wrong value.
getbalance before = getbalance atfer.

not 0.10 BTG , 0.00125 CENT , it is 10,000 times lesser

Good point, but 0 it's zero, if you prefer "0.00000000"

Take a look into PPC or NVC source (mainly kernel.cpp and kernel.h) and then you talk about stake ... At the moment, is better be quiet than to seem an ignorant.

I really wonder how people can recomend to deactivate something they dont know how it work ... amazing.

Sorry, I did no one recommendation. NVC, PPC or PingPongcoin,..., POW and POS are software designs not totems. I am speaking about people, people does not mine/spend resources if get nothing,...Software can sing about unicorns or other creatures. It's only an idea.

This dialog  is useless.

Already all said about calculations. If you has got 1,000 BTGs you has got 1 BTG.

And in the case of 0 stake, which is not the case as explained, do you prefer the 51% attack of the clones ... ?  Have you realized that anyone stake coin have not been 51% attacked? Why will be it eh?

And next month it will be the new stake, so if you are a little pacient it will be worth .

useless? you should be happy that people who are willing to use your software and willing to come here and post an issue in hopes it will get fixed instead of just leaving and having it affect the rest and have them leave too. I am a small miner, ive been on disability now for 9 months now and the last 7 have been with no work pay/insurance and waiting for disability to officially approve it.the only reason i mention that is i dont have the capability right now to upgrade my hardware to be a better miner.i have been watching this post today and yesterday and watching the replies and honestly im in amazement in the denial im seeing from bitgem.
If your job told you i cant pay you this month but wait til next month , i promise you , you will get a paycheck---would you wait? would you even continue to work for them?Majority will say no.Now this is what is posted on bitgems website:

BTG Bitgem Information

Why BTG BitGem?

It's a cryptocurrency not extant until now. PoW scrypt and PoS like NovaCoin, but adapted to gem's character, providing semi-scarce, precious and highly valuable currency properties. Mining a block you could to get up to 3 BTGs, standing the most representative gems: diamond, ruby and emerald ... who would not want it?

Features:

PoW scrypt.
PoS,
retargeting each 10 min.
difficulty adjustement each block,
semi-scarce: reward 3 BTG BitGems per block,
smoother reward adjustement, providing 3 BTGs as long as possible.
latest upstream updates from litecoin, ppcoin, novacoin incluided.
built with latest lib dependencies, enterenly with linux tool-chain.
installer provided.


no where does it say that the proof of stake this month will be any different then any other month.I first question that but then i look at these posts and i question why NEXT month will all the sudden be better and that we should wait---well maybe we should just wait on bitgem period without mining or trading for it until next month when it "might" be ready.This "zero" issue really hurts the small and maybe even medium miners greatly while rewards the heavy miners even further.Is this what bitcoins and alt coins want to promote??This "zero" issue is very evident here but i believe it also affects small miners in pools that get only fractions of shares that the top hashers get and i know this for fact---i get cheated some of my shares if not in the hundreds due to them being dust particles and was told now by pool operators that they were so far down the decimal list they accounted for "zero". believe it or not - i accepted that and try now to not stop mining until i have hundreds of shares so that i can still get a non "zero" balance. You have someone that comes up with a fix and you basically tell them a fix is not needed.To me thats telling us , we are not needed here any longer and we should move on until things get better here.To everyone reading this reply i wrote, i realize there is a bunch of personal information that was not necessary needed and i understand that and apologize to you now.I wanted to make it known that i cannot upgrade to get the higher grade hashes that will not result in getting "zero" bonus or "security" as it was put tonight.Thanks.

[BitJohn]

Is there any extra steps needed to get bitgems to get proof of stake interest? or is it just simply run the wallet

[BitJohn]

Big news coming for Bitgem shortly

[BitJohn]

Bitgem now listed now listed on cryptsy.com

[mullick]

Bitgem now listed now listed on cryptsy.com

This is great news. Thanks go to you and bigvern

[Oreganobag]

Indeed.

And if anyone wants to setup a pool, I can get a beefy server up and running in the US/CA, provide support, marketing, design so long as you can setup and manage the technical side. 40/60 split on gems (you get 60%) and I'll manage paying for the server on my own. I'm thinking 1-2% PPLNS. I don't see the other pool actively marketing, so this could be a good opportunity and experience for both of us.

Does p2pool work or do you want pushpool ?

Either or. I have little working knowledge on java and programming in general. I'm an independent direct response marketer, so I know how to get people to sign up and buy, but have little technical background outside of some HTML.

[mineral]

Bitgem now listed now listed on cryptsy.com

GReat!! Thanks BitJohn.

[mineral]

Indeed.

And if anyone wants to setup a pool, I can get a beefy server up and running in the US/CA, provide support, marketing, design so long as you can setup and manage the technical side. 40/60 split on gems (you get 60%) and I'll manage paying for the server on my own. I'm thinking 1-2% PPLNS. I don't see the other pool actively marketing, so this could be a good opportunity and experience for both of us.

Does p2pool work or do you want pushpool ?

Either or. I have little working knowledge on java and programming in general. I'm an independent direct response marketer, so I know how to get people to sign up and buy, but have little technical background outside of some HTML.

p2pool works for BTG.

[mullick]

Indeed.

And if anyone wants to setup a pool, I can get a beefy server up and running in the US/CA, provide support, marketing, design so long as you can setup and manage the technical side. 40/60 split on gems (you get 60%) and I'll manage paying for the server on my own. I'm thinking 1-2% PPLNS. I don't see the other pool actively marketing, so this could be a good opportunity and experience for both of us.

Does p2pool work or do you want pushpool ?

Either or. I have little working knowledge on java and programming in general. I'm an independent direct response marketer, so I know how to get people to sign up and buy, but have little technical background outside of some HTML.

p2pool works for BTG.

Yep p2pool would work well. Just remember payouts will take a few days because of the 520 confirmations. The same as all pools now.

[snaidervp]

the OP needs update with pools, there is only 1 there,

also i thought there was a btg giveway thread that seems i cant find anymore

SR.

[mullick]

the OP needs update with pools, there is only 1 there,

also i thought there was a btg giveway thread that seems i cant find anymore

SR.

The giveaway is locatred at the forums/// Here https://cryptocointalk.com/forum/173-bitgem-btg/

There is currently only one pool. We are hoping for more and I have put up bounties for various things

[snaidervp]

yeap found it

[YukonCoinelius]

ALERT - Stake Mining Broken for small values - DETAILS AND FIX

I have generated a BitGem stake with maximum debug options (see log below), and investigated the situation why stake-mining has been yielding 0 bonus. It's a different issue than what they fixed for Bitbar (although the wallet rounding fix for bitbar might *also* be necessary in BitGem, but first we have to *create* the right stake reward, before worrying about crediting the wallet).  Also note: This issue actually applies to all the stake-mined coins (btg, btb, yac, nvc, ppc, ...) and I am planning to repeat post in a separate topic.

In a nutshell (after *lots* of debug work, all bitgemmer thank-you gifts welcome!):

in main.cpp, GetProofOfStakeReward, the line

Code:

int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

is wrong for small values of nCoinAge (which result when the underlying transaction amounts are small).

When nCoinAge < 366, nSubsidy evaluates to 0 because of integer division truncation.

Because BitGem and BitBar deal mostly with small amounts, nCoinAge will almost always be less than 366, and so the formula yields 0 stake credit almost always (unless you have a very large bitgem transaction amount).


To illustrate, note these lines from the long debug log at end of posting:

coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891

You see “create=0.00” as the computed nSubsidy, when it should be near 0.00887

This is a 3-unit coin that was about 36 days old (3 * 36 = 108 coindays).
Since June-20, Stake Mining Interest rate in Bitgem ranges 1-3% - I believe 3% (0.03) at the current difficulty.
So mathematically, the stake nSubsidy should be  

Code:

108 * 33 / (365 * 33 + 8) * 0.03 = 0.00887

But because all the numbers are internally represented as integers, the integer division truncation occurs.

Specifically:

Code:

 (108 * 33 / (365 * 33 + 8)) = 0

with the integer divide.
...

FALSE

Code:

108 * 33 / (365 * 33 + 8) * DOUBLE  = DOUBLE 

Because casting conversion, the result will be a DOUBLE, and != 0 because nSubsidy=0.015 * CENT

And, one more time, this month stake reward is not 3%, else  0.015 % , so 0.00015  ,

Code:

108 * 33 / (365 * 33 + 8) *  0.00015  = 0.000044354102713017506015099975109931 

I suppose you understand that printed number in log is not "the real representation"  of float representation in memory (or CPU registry) ...

Well, this debate is good in any case ... no.

Hi mineral, I hope you will see it clearly in just a moment. It's a rather subtle bug, which no other stakecoin developer has noticed yet either.

As I said above, in the formula

Code:

int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

*all* the variables and numbers are integers. There are no doubles. The numbers *represent* decimal values, but are actually integer values, scaled by a scaling factor.

Right on that line, you can see nSubsidy is declared int64, and a little further up in that function is the declaration
int64 nRewardCoinYear;
and also nCoinAge is int64 defined in the parameters of the function like this:
int64 GetProofOfStakeReward(int64 nCoinAge, unsigned int nBits, unsigned int nTime)

So all the values in the nSubsidy formula are integers, thus integer division occurs, which truncates to 0 for small values of nCoinAge.
Therefore small transaction inputs yield 0 stake reward currently.

ASIDE: Just fyi, what it means that decimals are stored as scaled integers:
When the stake reward is “3%” conceptually, which credits 0.03 of a bitgem on 1 bitgem per year, the internal integer variable holding “3%” is nRewardCoinYear = 3 * CENT = 30000 (CENT is defined as 10000 in util.h)  In the old interest schedule, it defined nRewardCoinYear = 0.015 * CENT. What is happening in that formula is, because of the double constant 0.015, CENT gets implicitly upconverted to a double, then the computation is 0.015 * 10000.0 = 150.0, which then gets implicitly downconverted back to an integer 150 to store in nRewardCoinYear, since that is an int64 variable. (you can't store a double in an integer var.)


In regards you saying the interest rate is still 0.015 %, I think you must not have checked the code lately.
On June 20, 2013 it switched to the new schedule, 1-3%, and the detailed debug investigation I posted is with the new schedule.
Again in that GetProofOfStakeReward() function, you can see the line

Code:

if(fTestNet || nTime > PROTOCOL_SWITCH_TIME) 

which says if the time is after the protocol switch time, then use the new interest schedule.
And the switch time is defined in main.h as:

Code:

static const unsigned int PROTOCOL_SWITCH_TIME = 1371686400; // 20 Jun 2013 00:00:00 

So we are definitely on the new schedule now, which has a variable interest rate 1-3%, computed as between:

Code:

bnLowerBound = 1 * CENT = 10000 (which represents 1%)
bnUpperBound = bnRewardCoinYearLimit = MAX_MINT_PROOF_OF_STAKE = 3 * CENT = 30000 (which represents 3%)

For any interested readers, the function we are talking about is GetProofOfStakeReward(), at line 979 in this file:
https://github.com/bitgem/bitgem/blob/master/src/main.cpp


I hope it's clear now, mineral, yes?   And thanks for your good support on BitGem.

If you still do not feel confident applying this fix, I will push it upstream to the PPC/NVC developers first, and you can pick up the changes after. But it will obviously take longer, and really BitGem (and BitBar) are the coins affected the most (because the transaction amounts are generally small).



SUMMARY FOR USERS

* Transactions less than about 12 btg get 0 stake interest currently.  It doesn't matter what the total wallet balance is - even if it were 1000, if all the transaction inputs are 3, 5, 0.422, etc  each of those gets 0 interest currently, so interest overall is 0.

* The wallet is continuously stake mining in the background.  It uses up your "CoinAge" to generate the interest.

* Because of these 2 factors, I recommend you set reservebalance=10000 in bitgem.conf.  That will save your CoinAge from getting used up.  After this is fixed you can set reservebalance=0 (or some small value), and then you should get more back-credit interest from all your accrued coinAge.

* This same issue affects all the stake coins (PPC, NVC, YAC, BTB, ...)  but it doesn't matter as much for the coins where most transaction amounts are higher than 12.)

* Thank you gifts appreciated  BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N

[mineral]

ALERT - Stake Mining Broken for small values - DETAILS AND FIX

I have generated a BitGem stake with maximum debug options (see log below), and investigated the situation why stake-mining has been yielding 0 bonus. It's a different issue than what they fixed for Bitbar (although the wallet rounding fix for bitbar might *also* be necessary in BitGem, but first we have to *create* the right stake reward, before worrying about crediting the wallet).  Also note: This issue actually applies to all the stake-mined coins (btg, btb, yac, nvc, ppc, ...) and I am planning to repeat post in a separate topic.

In a nutshell (after *lots* of debug work, all bitgemmer thank-you gifts welcome!):

in main.cpp, GetProofOfStakeReward, the line

Code:

int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

is wrong for small values of nCoinAge (which result when the underlying transaction amounts are small).

When nCoinAge < 366, nSubsidy evaluates to 0 because of integer division truncation.

Because BitGem and BitBar deal mostly with small amounts, nCoinAge will almost always be less than 366, and so the formula yields 0 stake credit almost always (unless you have a very large bitgem transaction amount).


To illustrate, note these lines from the long debug log at end of posting:

coin age bnCoinDay=108
GetProofOfStakeReward() : lower=10000 upper=30000 mid=20000
GetProofOfStakeReward() : lower=20000 upper=30000 mid=25000
GetProofOfStakeReward(): create=0.00 nCoinAge=108 nBits=503964891

You see “create=0.00” as the computed nSubsidy, when it should be near 0.00887

This is a 3-unit coin that was about 36 days old (3 * 36 = 108 coindays).
Since June-20, Stake Mining Interest rate in Bitgem ranges 1-3% - I believe 3% (0.03) at the current difficulty.
So mathematically, the stake nSubsidy should be  

Code:

108 * 33 / (365 * 33 + 8) * 0.03 = 0.00887

But because all the numbers are internally represented as integers, the integer division truncation occurs.

Specifically:

Code:

 (108 * 33 / (365 * 33 + 8)) = 0

with the integer divide.
...

FALSE

Code:

108 * 33 / (365 * 33 + 8) * DOUBLE  = DOUBLE 

Because casting conversion, the result will be a DOUBLE, and != 0 because nSubsidy=0.015 * CENT

And, one more time, this month stake reward is not 3%, else  0.015 % , so 0.00015  ,

Code:

108 * 33 / (365 * 33 + 8) *  0.00015  = 0.000044354102713017506015099975109931 

I suppose you understand that printed number in log is not "the real representation"  of float representation in memory (or CPU registry) ...

Well, this debate is good in any case ... no.

Hi mineral, I hope you will see it clearly in just a moment. It's a rather subtle bug, which no other stakecoin developer has noticed yet either.

As I said above, in the formula

Code:

int64 nSubsidy = nCoinAge * 33 / (365 * 33 + 8) * nRewardCoinYear;

*all* the variables and numbers are integers. There are no doubles. The numbers *represent* decimal values, but are actually integer values, scaled by a scaling factor.

Right on that line, you can see nSubsidy is declared int64, and a little further up in that function is the declaration
int64 nRewardCoinYear;
and also nCoinAge is int64 defined in the parameters of the function like this:
int64 GetProofOfStakeReward(int64 nCoinAge, unsigned int nBits, unsigned int nTime)

So all the values in the nSubsidy formula are integers, thus integer division occurs, which truncates to 0 for small values of nCoinAge.
Therefore small transaction inputs yield 0 stake reward currently.

ASIDE: Just fyi, what it means that decimals are stored as scaled integers:
When the stake reward is “3%” conceptually, which credits 0.03 of a bitgem on 1 bitgem per year, the internal integer variable holding “3%” is nRewardCoinYear = 3 * CENT = 30000 (CENT is defined as 10000 in util.h)  In the old interest schedule, it defined nRewardCoinYear = 0.015 * CENT. What is happening in that formula is, because of the double constant 0.015, CENT gets implicitly upconverted to a double, then the computation is 0.015 * 10000.0 = 150.0, which then gets implicitly downconverted back to an integer 150 to store in nRewardCoinYear, since that is an int64 variable. (you can't store a double in an integer var.)


In regards you saying the interest rate is still 0.015 %, I think you must not have checked the code lately.
On June 20, 2013 it switched to the new schedule, 1-3%, and the detailed debug investigation I posted is with the new schedule.
Again in that GetProofOfStakeReward() function, you can see the line

Code:

if(fTestNet || nTime > PROTOCOL_SWITCH_TIME) 

which says if the time is after the protocol switch time, then use the new interest schedule.
And the switch time is defined in main.h as:

Code:

static const unsigned int PROTOCOL_SWITCH_TIME = 1371686400; // 20 Jun 2013 00:00:00 

So we are definitely on the new schedule now, which has a variable interest rate 1-3%, computed as between:

Code:

bnLowerBound = 1 * CENT = 10000 (which represents 1%)
bnUpperBound = bnRewardCoinYearLimit = MAX_MINT_PROOF_OF_STAKE = 3 * CENT = 30000 (which represents 3%)

For any interested readers, the function we are talking about is GetProofOfStakeReward(), at line 979 in this file:
https://github.com/bitgem/bitgem/blob/master/src/main.cpp


I hope it's clear now, mineral, yes?   And thanks for your good support on BitGem.

If you still do not feel confident applying this fix, I will push it upstream to the PPC/NVC developers first, and you can pick up the changes after. But it will obviously take longer, and really BitGem (and BitBar) are the coins affected the most (because the transaction amounts are generally small).



SUMMARY FOR USERS

* Transactions less than about 12 btg get 0 stake interest currently.  It doesn't matter what the total wallet balance is - even if it were 1000, if all the transaction inputs are 3, 5, 0.422, etc  each of those gets 0 interest currently, so interest overall is 0.

* The wallet is continuously stake mining in the background.  It uses up your "CoinAge" to generate the interest.

* Because of these 2 factors, I recommend you set reservebalance=10000 in bitgem.conf.  That will save your CoinAge from getting used up.  After this is fixed you can set reservebalance=0 (or some small value), and then you should get more back-credit interest from all your accrued coinAge.

* This same issue affects all the stake coins (PPC, NVC, YAC, BTB, ...)  but it doesn't matter as much for the coins where most transaction amounts are higher than 12.)

* Thank you gifts appreciated  BitGem: gWhCCz9P4TDU2Uj2ZNgwpCvWEf7DhXTg9N

Well, thanks. Very appreciated one more time. I will test stake and do commits related if applicable for next release.

reservebalance=0 is not recommended because security reasons and, in addtion, you could forget it in conf file and losing all stake reward after update, but you are free of using if you want it. Besides, may stake is finishing just now.

Anyway, contentious of inflaction is best than an inflactionary coin, so this only  month with low stake reward is a very good scenario for early bitgemers.

Bye.

[mullick]

Glad to hear your looking into and thank you for pointing it out Yukon. I do agree that you should not set the reserve baklance unless you may need to spend the coins. You are securing the network Just my stake minting so you are not really losing anything.

When the fix gets implemented if needed and you took out the reserve balance would you not have to wait another 30 days to be eligible again? So even if you had staked coins you would only lose the confirmation time?

I think the early dumpers are just about done. Time for bitgems to find there price over the coming days

[Badman0316]

the price was undervalue
it must be rise up

[nullbitspectre1848]

Don't know how I missed this one until now.  Looks cool, I do like gems and minerals  If anyone would like to donate a little to help get my balance off 0 and get me started that would be cool

gm7jijQqkHyAohBUViPjhc24FXSmJeBL5H

Is there still only the one pool?