Pages:
Author

Topic: [ANN] Noirbits Update required Improved algos !!!! - page 16. (Read 74494 times)

legendary
Activity: 882
Merit: 1000
I think a retarget tme of 20 minutes is most ideal, with only a 80% change allowable
legendary
Activity: 882
Merit: 1000
block rate is slow right now, we are working on a patch.
newbie
Activity: 46
Merit: 0
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...?
hero member
Activity: 695
Merit: 500
LOOK at that PRICE RISE!!!!!!!!!!!!!!!!!!!!!!!!!!!!   

Yes that is amazing, happy I had bought at 0.000084 Smiley
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 Smiley
legendary
Activity: 882
Merit: 1000
LOOK at that PRICE RISE!!!!!!!!!!!!!!!!!!!!!!!!!!!!   
hero member
Activity: 490
Merit: 500
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.
full member
Activity: 154
Merit: 100
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()
newbie
Activity: 42
Merit: 0
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

Code:
// Only change once per interval
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())

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;

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;

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?
full member
Activity: 154
Merit: 100
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

Code:
// Only change once per interval
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())

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;

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;

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 ?
legendary
Activity: 882
Merit: 1000
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;

and

Code:
static const int64 nReTargetHistoryFact = 4; // look at 4 times the retarget
                                             // 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;
full member
Activity: 162
Merit: 100
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.
newbie
Activity: 42
Merit: 0
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?
legendary
Activity: 882
Merit: 1000
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?
full member
Activity: 162
Merit: 100
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.
full member
Activity: 154
Merit: 100
Sure thing, but lunch's over Sad I'll get back to it tonight..

Other than that, we're 17 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
legendary
Activity: 882
Merit: 1000
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.
legendary
Activity: 1197
Merit: 1000

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...
full member
Activity: 154
Merit: 100
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...
newbie
Activity: 46
Merit: 0

It stoped paying out at around 1-2am last night according to my miners. nrb.coinmine.pl that is.
legendary
Activity: 1197
Merit: 1000
coinmine down?

bloody eloipool... I came back to stratum + pushpoold now.
Pages:
Jump to: