Topic: [ANN] Noirbits Update required Improved algos !!!! - page 16. (Read 74508 times)
I think a retarget tme of 20 minutes is most ideal, with only a 80% change allowable
block rate is slow right now, we are working on a patch.
Is it normal for the confirmations to be taking hours currently? I sent some Noir to Crypsy 2 hours and 30 min ago and so far it has 1 confirmation...?
LOOK at that PRICE RISE!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Yes that is amazing, happy I had bought at 0.000084
Can I ask what the NRB bank is doing? When do you think will it be released? Sometime soon or still weeks or month till release?
By the way, nice coin you made, like it
LOOK at that PRICE RISE!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Is it possible to get Noirbits off of coinchoose to prevent these difficulty / hashrate swings? I don't think they're very good for the success of the currency. It seems like bitgem was taken off of coinchoose, not sure how that happened.
that is an option, but it's being listed on coinchoose has caused the price to rise, i think a update to the algo to put it in the more stable bracket is a better idea. your thoughts?
BitGem was removed due to inability to calc the true reward for the next block (or the fact that no one could give me a good formula). As an aside, variable block rewards give CoinChoose the most fits.
Hum... good point, however, blocks do carry a timestamp. Just need to find out how it's generated, and use the same method...
Edit Looks like transaction times are generated using a call to GetAdjustedTime(). I'll check up on that later, but that could be the good call instead of time()
Edit Looks like transaction times are generated using a call to GetAdjustedTime(). I'll check up on that later, but that could be the good call instead of time()
Well I like oatmo's idea... aim for retargets every hour, with a max time until retarget... quite simple to implement :
Replace l. 878-879 in main.cpp
With the following :
We would also need to adjust l. 836 of main.cpp, currently diff. retargets every two hours :
Would become
Proposed changes here would give us retarget every hour, and a retarget on next block if no retarget happened for more than 4 hours. What do you think ?
Replace l. 878-879 in main.cpp
Code:
// Only change once per interval
if ((pindexLast->nHeight+1) % nInterval != 0)
if ((pindexLast->nHeight+1) % nInterval != 0)
With the following :
Code:
// Only change once per interval unless last retarget occurred more than nMaxTimeInterval seconds ago
unsigned int nMaxTimeInterval = 14400;
if ((pindexLast->nHeight+1) % nInterval != 0 && pindexLast->nTime + nMaxTimeInterval > time())
unsigned int nMaxTimeInterval = 14400;
if ((pindexLast->nHeight+1) % nInterval != 0 && pindexLast->nTime + nMaxTimeInterval > time())
We would also need to adjust l. 836 of main.cpp, currently diff. retargets every two hours :
Code:
static const int64 nTargetTimespan = 1 * 2 * 60 * 60; // Noirbits: 2 hour
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
Would become
Code:
static const int64 nTargetTimespan = 3600; // Noirbits: 1 hour
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
Proposed changes here would give us retarget every hour, and a retarget on next block if no retarget happened for more than 4 hours. What do you think ?
I have been thinking about this as well, but how will this change work across timezones as well as machines that have modified date times that could attach the retarget if the block is found?
Well I like oatmo's idea... aim for retargets every hour, with a max time until retarget... quite simple to implement :
Replace l. 878-879 in main.cpp
With the following :
We would also need to adjust l. 836 of main.cpp, currently diff. retargets every two hours :
Would become
Proposed changes here would give us retarget every hour, and a retarget on next block if no retarget happened for more than 4 hours. What do you think ?
Replace l. 878-879 in main.cpp
Code:
// Only change once per interval
if ((pindexLast->nHeight+1) % nInterval != 0)
if ((pindexLast->nHeight+1) % nInterval != 0)
With the following :
Code:
// Only change once per interval unless last retarget occurred more than nMaxTimeInterval seconds ago
unsigned int nMaxTimeInterval = 14400;
if ((pindexLast->nHeight+1) % nInterval != 0 && pindexLast->nTime + nMaxTimeInterval > time())
unsigned int nMaxTimeInterval = 14400;
if ((pindexLast->nHeight+1) % nInterval != 0 && pindexLast->nTime + nMaxTimeInterval > time())
We would also need to adjust l. 836 of main.cpp, currently diff. retargets every two hours :
Code:
static const int64 nTargetTimespan = 1 * 2 * 60 * 60; // Noirbits: 2 hour
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
Would become
Code:
static const int64 nTargetTimespan = 3600; // Noirbits: 1 hour
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
Proposed changes here would give us retarget every hour, and a retarget on next block if no retarget happened for more than 4 hours. What do you think ?
Is it possible to get Noirbits off of coinchoose to prevent these difficulty / hashrate swings? I don't think they're very good for the success of the currency. It seems like bitgem was taken off of coinchoose, not sure how that happened.
that is an option, but it's being listed on coinchoose has caused the price to rise, i think a update to the algo to put it in the more stable bracket is a better idea. your thoughts?
I think it would be better to adjust the algo for the coin as people regardless of the site will come and go based on profitability. What is the way we want to approach the algo for recalculating?
retarget times and percentages
current
Code:
static const int64 nTargetTimespan = 1 * 2 * 60 * 60; // Noirbits: 2 hour
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
static const int64 nTargetSpacing = 120; // Noirbits: 2 minute blocks
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
and
Code:
static const int64 nReTargetHistoryFact = 4; // look at 4 times the retarget
// interval into the block history
// interval into the block history
also
Code:
// Limit adjustment step
int64 nActualTimespan = 0;
if (pindexLast->nHeight > COINFIX1_BLOCK)
// obtain average actual timespan
nActualTimespan = (pindexLast->GetBlockTime() - pindexFirst->GetBlockTime())/nReTargetHistoryFact;
else
nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
printf(" nActualTimespan = %"PRI64d" before bounds\n", nActualTimespan);
if (nActualTimespan < nTargetTimespan/4)
nActualTimespan = nTargetTimespan/4;
if (nActualTimespan > nTargetTimespan*4)
nActualTimespan = nTargetTimespan*4;
int64 nActualTimespan = 0;
if (pindexLast->nHeight > COINFIX1_BLOCK)
// obtain average actual timespan
nActualTimespan = (pindexLast->GetBlockTime() - pindexFirst->GetBlockTime())/nReTargetHistoryFact;
else
nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
printf(" nActualTimespan = %"PRI64d" before bounds\n", nActualTimespan);
if (nActualTimespan < nTargetTimespan/4)
nActualTimespan = nTargetTimespan/4;
if (nActualTimespan > nTargetTimespan*4)
nActualTimespan = nTargetTimespan*4;
I think making adjustments is the right way to go, but in 12 hours or so there probably will be another massive swing that might be averted by getting it off coinchoose temporarily. I think the interest generated by the listing on coinchoose won't go away if it is delisted for a while.
Is it possible to get Noirbits off of coinchoose to prevent these difficulty / hashrate swings? I don't think they're very good for the success of the currency. It seems like bitgem was taken off of coinchoose, not sure how that happened.
that is an option, but it's being listed on coinchoose has caused the price to rise, i think a update to the algo to put it in the more stable bracket is a better idea. your thoughts?
I think it would be better to adjust the algo for the coin as people regardless of the site will come and go based on profitability. What is the way we want to approach the algo for recalculating?
Is it possible to get Noirbits off of coinchoose to prevent these difficulty / hashrate swings? I don't think they're very good for the success of the currency. It seems like bitgem was taken off of coinchoose, not sure how that happened.
that is an option, but it's being listed on coinchoose has caused the price to rise, i think a update to the algo to put it in the more stable bracket is a better idea. your thoughts?
Is it possible to get Noirbits off of coinchoose to prevent these difficulty / hashrate swings? I don't think they're very good for the success of the currency. It seems like bitgem was taken off of coinchoose, not sure how that happened.
Sure thing, but lunch's over 
I'll get back to it tonight..
Other than that, we're17 41 blocks from retarget (~30mn 12hrs at current hashrate) if I'm not mistaken, which should bring diff back to a more reasonnable value... I really got confused on this calc, sorry :s
I'll get back to it tonight..Other than that, we're
ok, please look into the changing retarget times, maybe to every 15 blocks or 30 minutes. Since difficulty is high, i've dropped everything so i can put my all to try again for the merged mining.
It stoped paying out at around 1-2am last night according to my miners. nrb.coinmine.pl that is.
Last block was found at 2013-07-02 07:04:53 AM CET...
Hum my proposed patch only makes a difference if you call getnetworkhashps with -1... but we should all be checking hashrate using -1 given it reports hashrate since the last diff. change and the hashrate calc is dependent on current difficulty.
Calling the function with any other value is bound to give incorrect hashrates since the calculation will include blocks that may have different targets.... I patched my client to test it, and pushed the update to miners-united, seems to be reporting more accurately network hashrate now (12Mhps instead of 65...)
Or we could change the default parameter value of getnetworkhashps to -1 instead of 120...
Calling the function with any other value is bound to give incorrect hashrates since the calculation will include blocks that may have different targets.... I patched my client to test it, and pushed the update to miners-united, seems to be reporting more accurately network hashrate now (12Mhps instead of 65...)
Or we could change the default parameter value of getnetworkhashps to -1 instead of 120...
It stoped paying out at around 1-2am last night according to my miners. nrb.coinmine.pl that is.
coinmine down?
bloody eloipool... I came back to stratum + pushpoold now.
Jump to: