Pages:
Author

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

full member
Activity: 162
Merit: 100
I talked to sal002 and he said he'd take it off of coinchoose in a few hours.

About 14 hours until the next retarget according to minersunited.

EDIT: Its been taken off coinchoose! 12-13 hours now at current hash
full member
Activity: 154
Merit: 100
It's all done... I've issued a pull request on the Testing branch on Github. Its' just missing the new 30 target block, will do it tomorrow.
newbie
Activity: 42
Merit: 0
I believe we should be off coinchoose for now. I am all for removing that 4 retarget difference, as it is killing us when it drops and then continues to drop even once we have a huge increase. I do think though that the difficulty change that comes from coinchoose would also allow us to get people updated in a short period when the hash rate is low because it takes almost a day to get the difficulty back down. But that shouldn't matter if we put in a target block as long as we don't see a huge spike again too quickly.

Also I wouldn't say it is dead, I thought the same was going to be said for FTC which had almost a whole month before a retarget because of the same issues.
full member
Activity: 154
Merit: 100
Yeah I know, all altcoins are dead... but whatever.
newbie
Activity: 42
Merit: 0
Noribits are dead, going absolutely no where, dont waste your time... geez lol. NEXT
full member
Activity: 154
Merit: 100
All right, thanks. I'm working on new diff rules as of now, almost done.
hero member
Activity: 695
Merit: 500
Iam for taking it off of coinchoose untill the retargeting has bean modified, then put it back on as fast as possible Wink
full member
Activity: 154
Merit: 100
I think so... everyone ?
legendary
Activity: 882
Merit: 1000
are we in concensus?
full member
Activity: 154
Merit: 100
Delist. I'm all for it, would give us time to adjust Noirbits. I'm currently working on the diff. algo, will get back @ you when I'm done.

Basically, the changes I'm currently implementing are :
* 30 block retarget
* Capped increases (80% max of previous diff) & decreases
* Removal of the 4x retarget history, which is not compatible which high variations of hashrate.
* 4 hour hard limit for retarget : drop difficulty to whatever it should be, since it means hash power is way below difficulty.

However, I've been thinking about the 4x retarget history, and I can't make up my mind :

* Get rid of it. The 80% cap will do the same job.
OR
* Keep it, but increase the interval to a higher value, maybe 10x to 20x instead of 4x. Hell, why not 48x (would rewind two days of blocks) to stabilize difficulty. It would smoothen difficulty changes out.

If you keep it, and someone drops 100MH/s on Noirbits after we've been running for days at 30MH/s, doesn't that cause use to generate a ton of extra blocks that we don't want? That doesn't seem good, because it let's the system generate more blocks than it was designed to do.

I think some history is good because it provides ballast to keep the system from wildly fluctuating, but weighted accordingly. That's why I suggested something like 48%, 32%, 12%, 8%. I think the 4 hour limit is the most important thing right now (along with a 30 block retarget instead of a 60 block retarget).

Yeah, well,you made up my mind I guess Smiley The 80% cap would have the same effect though... if you think about it.
member
Activity: 104
Merit: 10
Delist. I'm all for it, would give us time to adjust Noirbits. I'm currently working on the diff. algo, will get back @ you when I'm done.

Basically, the changes I'm currently implementing are :
* 30 block retarget
* Capped increases (80% max of previous diff) & decreases
* Removal of the 4x retarget history, which is not compatible which high variations of hashrate.
* 4 hour hard limit for retarget : drop difficulty to whatever it should be, since it means hash power is way below difficulty.

However, I've been thinking about the 4x retarget history, and I can't make up my mind :

* Get rid of it. The 80% cap will do the same job.
OR
* Keep it, but increase the interval to a higher value, maybe 10x to 20x instead of 4x. Hell, why not 48x (would rewind two days of blocks) to stabilize difficulty. It would smoothen difficulty changes out.

If you keep it, and someone drops 100MH/s on Noirbits after we've been running for days at 30MH/s, doesn't that cause use to generate a ton of extra blocks that we don't want? That doesn't seem good, because it let's the system generate more blocks than it was designed to do.

I think some history is good because it provides ballast to keep the system from wildly fluctuating, but weighted accordingly. That's why I suggested something like 48%, 32%, 12%, 8%. I think the 4 hour limit is the most important thing right now (along with a 30 block retarget instead of a 60 block retarget).
full member
Activity: 154
Merit: 100
Delist. I'm all for it, would give us time to adjust Noirbits. I'm currently working on the diff. algo, will get back @ you when I'm done.

Basically, the changes I'm currently implementing are :
* 30 block retarget
* Capped increases (80% max of previous diff) & decreases
* Removal of the 4x retarget history, which is not compatible which high variations of hashrate.
* 4 hour hard limit for retarget : drop difficulty to whatever it should be, since it means hash power is way below difficulty.

However, I've been thinking about the 4x retarget history, and I can't make up my mind :

* Get rid of it. The 80% cap will do the same job.
OR
* Keep it, but increase the interval to a higher value, maybe 10x to 20x instead of 4x. Hell, why not 48x (would rewind two days of blocks) to stabilize difficulty. It would smoothen difficulty changes out.
full member
Activity: 129
Merit: 100
Yeah, seriously I say delist it. With these insane spikes in difficulty, I just had to stop mining Noirbits (and I have been mining it 24/7 for more than a week). In hours, I only made 1-2 NRB...
full member
Activity: 162
Merit: 100
If we could get a few more posts in this thread asking to delist for a while, then it would happen
member
Activity: 104
Merit: 10
Yes, the problems you're describing are resulting from the listing on coinchoose

EDIT:
Essentially what happens is as soon as the difficulty adjusts down, the profitability of the coin on coinchoose jumps by a large amount. This makes it 500% profitable to mine, and a large amount of miners jump on the coin. Then once the difficulty adjusts to the new hashrate, then those people stop mining noirbits making the hashrate low and the difficulty extremely high, making it take hours to find a block. This is bad for miners and for users of the coin as transfers also take hours.

When its listed on coinchoose there is no incentive for miners to mine through high difficulty periods as they know once the high difficulty period is over, other miners will jump on the coin taking away some of the profit, and making it high difficulty again. Also, this causes crashes in price (The highest offer is down to 0.00006 right now) because miners who only are mining the coin at low difficulty, and not because they believe that the coin is good will just dump when they get their NRB.

Then lets ask them to delist us for a week while we get this stuff fixed unless there is violent opposition.
hero member
Activity: 490
Merit: 500
As I mentioned to JDDev - if you all come to a consensus to remove from CoinChoose, I will remove it.  I think there is a different issue if the profitability is jumping that high, though, as CoinWarz would also pick it up.
full member
Activity: 162
Merit: 100
Yes, the problems you're describing are resulting from the listing on coinchoose

EDIT:
Essentially what happens is as soon as the difficulty adjusts down, the profitability of the coin on coinchoose jumps by a large amount. This makes it 500% profitable to mine, and a large amount of miners jump on the coin. Then once the difficulty adjusts to the new hashrate, then those people stop mining noirbits making the hashrate low and the difficulty extremely high, making it take hours to find a block. This is bad for miners and for users of the coin as transfers also take hours.

When its listed on coinchoose there is no incentive for miners to mine through high difficulty periods as they know once the high difficulty period is over, other miners will jump on the coin taking away some of the profit, and making it high difficulty again. Also, this causes crashes in price (The highest offer is down to 0.00006 right now) because miners who only are mining the coin at low difficulty, and not because they believe that the coin is good will just dump when they get their NRB.
member
Activity: 104
Merit: 10
What would also be good is if we could detect if say 5 blocks were found too quickly in a row and then do a retarget then. Once we make the changes to the difficulty to allow it to lower faster, it just means that more people will jump back on until it sky rockets again and then comes back down for those who are leaving their miners on it for that period of time keeping the coin going. Just another thing for us to consider.
Yes. We are seeing a real seesaw right now. We have to figure out the right ballast for the algorithm. They should design a test simulator into the open source along with a test suite which does stuff like this, so the algorithm can be refined before the coin is launched.

Having said that, I went to bed last night adding hashes to the network, because I thought that in another 20 blocks the hashrate would adjust down. It did, but went too low and we got 500 blocks over 6 hours, but I have almost no coin this morning, so I think that large miners jumped on it as soon as the difficulty went low, taking all the coin. We definitely need it to react much faster to adds and drops.

Instead of using the average over the last 4 retargets, how about an exponential weighted average, like 50%, 30%, 12%, 8%. Unlimited drops (how about only when we hit the 4 hour limit, but not for a regular 60 block retarget).

The issue with implementing a test suite is... well the source code. It needs heavy refactoring to achieve simulation of hashrate peaks without the hardware.

Other than that, I second the unlimited drop only if 4 hour interval is reached. I don't know where the 4 times rewind comes from (its not in Litecoin source), but we've seen its disastrous effects : it's a shitload of crap. We need to get rid of it ASAP, but we can't push it just like that. We can conditionally remove it starting at block N, where N needs to be decided so it gives enough time for users to update the client. That way we can push the change immediately, and have it effective in about a week.

Edit Also, I think we need to raise min target, it's currently way too low compared to the available hashing power.

I think the spikes up will be taken care of with 30 block retargets instead of 60, with a better weighting over the last 4 retargets. The real problem is when the hashing power drops off. This morning my client says that network has 180MH/s up from 5MH/s last night. Is that all from coinchoose reporting a rediculously low difficulty and everyone jumping on? If so, then I change my vote to remove us from coinchoose for a week to get the client updated before we go back on. I'm now thinking that even a max of a 3 hour retarget would be better than 4 to handle fluctuations like this (and I still think an unlimited drop in the case of a time forced retarget only).

Now it's reporting 130MH/s, so maybe we will be spared the huge drop which causes a 4 day wait for the retarget, followed by the difficulty dropping way too low.
legendary
Activity: 882
Merit: 1000
as i said, this is a community thing, if the active people are in agreement then let's do it.
full member
Activity: 154
Merit: 100
What would also be good is if we could detect if say 5 blocks were found too quickly in a row and then do a retarget then. Once we make the changes to the difficulty to allow it to lower faster, it just means that more people will jump back on until it sky rockets again and then comes back down for those who are leaving their miners on it for that period of time keeping the coin going. Just another thing for us to consider.
Yes. We are seeing a real seesaw right now. We have to figure out the right ballast for the algorithm. They should design a test simulator into the open source along with a test suite which does stuff like this, so the algorithm can be refined before the coin is launched.

Having said that, I went to bed last night adding hashes to the network, because I thought that in another 20 blocks the hashrate would adjust down. It did, but went too low and we got 500 blocks over 6 hours, but I have almost no coin this morning, so I think that large miners jumped on it as soon as the difficulty went low, taking all the coin. We definitely need it to react much faster to adds and drops.

Instead of using the average over the last 4 retargets, how about an exponential weighted average, like 50%, 30%, 12%, 8%. Unlimited drops (how about only when we hit the 4 hour limit, but not for a regular 60 block retarget).

The issue with implementing a test suite is... well the source code. It needs heavy refactoring to achieve simulation of hashrate peaks without the hardware.

Other than that, I second the unlimited drop only if 4 hour interval is reached. I don't know where the 4 times rewind comes from (its not in Litecoin source), but we've seen its disastrous effects : it's a shitload of crap. We need to get rid of it ASAP, but we can't push it just like that. We can conditionally remove it starting at block N, where N needs to be decided so it gives enough time for users to update the client. That way we can push the change immediately, and have it effective in about a week.

Edit Also, I think we need to raise min target, it's currently way too low compared to the available hashing power.
Pages:
Jump to: