[ANN] Noirbits Update required Improved algos !!!!

[John122]

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...

[stbgefltc]

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.

[oatmo]

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).

[stbgefltc]

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 The 80% cap would have the same effect though... if you think about it.

[barwizi]

are we in concensus?

[stbgefltc]

I think so... everyone ?

[bahamapascal]

Iam for taking it off of coinchoose untill the retargeting has bean modified, then put it back on as fast as possible

[stbgefltc]

All right, thanks. I'm working on new diff rules as of now, almost done.

[Breen2543]

Noribits are dead, going absolutely no where, dont waste your time... geez lol. NEXT

[stbgefltc]

Yeah I know, all altcoins are dead... but whatever.

[TheRickTM]

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.

[stbgefltc]

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.

[JDDev]

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

[stbgefltc]

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

Just a quick note on retarget times on miners-united : they're based off the current network hashrate, which itself is based upon the time it took to find all blocks found since last retarget. So you need to wait a few blocks (I'd say at least 10) after retargets until the measure is somewhat accurate.

Hashrate measurement is hardly ever accurate if you take into account diff. changes, luck, and so on... Most pools that display hashrates I believe use the last 120 blocks (it's the default of getnetworkhashps) to sample find times and estimate hashrate, but with Noirbits, that's bound to be off since it will always span two retargets.

As you can see, in practice, it's been almost a day since last retarget whilst the pool was announcing 12 to 14 hours for next retarget... I'm trying to find a more accurate way to sample hashrate and retarget estimates, but until then, it at least spares you the mental math

[oatmo]

Just kicked in another 3 miners to help get us over the hump.

[oatmo]

Thinking about the adjustment algorithm.

Assuming that we change the retarget to 30 blocks:

1) When difficulty goes up, it seems fine to just use the last 30 blocks to calculate the new difficulty (with some max change)
2) When difficulty goes down, it seems fine to just use the last 30 blocks to calculate the new difficulty (with some max change)

My statistics are terrible, but is looks like 30 blocks give you a +-10% with 75% confidence. That seems fine. My real concern is the 4 hour forced retarget. Let's take the worst case, that in 6 hours we only get a single block. Since this is random, that one sample is not nearly enough to set the new difficulty with any confidence at all. I'm not sure the best way to handle this situation, but I'm going to propose something different that what we were already going down. Currently the regular retargets can change the difficulty by a max of 80% in one direction (this seems reasonable). What if we make it depend on the current block, but make the max amount of change 55-60% instead of 80 so that we can dampen the fluctuations. If we're worried about how quickly we will recover, then we should use a smaller forced retarget (like 3 hours), instead of using a bigger percentage change at 4 hours. We also need a hard floor on the difficulty. We can either pick the value, or my suggestion is that we do something like 90% of the lowest calculated block from the last week (the lowest calculated hashrate from 168 retargets), or some shorter period of time. This gives us low bound for where you would expect the hash rate to go. This calculation is going to be a little tricky because of the 4 hour force retarget possibility.

Comments?

Oatmo

[stbgefltc]

Seems a bit too complex... the four hour retarget is to avoid killing the coin with massive hashrate drops.... look @ CHNCoin...

[stbgefltc]

By the way, anyone here has the know-how to update makefiles ?

[oatmo]

By the way, anyone here has the know-how to update makefiles ?

What do you need?

[oatmo]

Seems a bit too complex... the four hour retarget is to avoid killing the coin with massive hashrate drops.... look @ CHNCoin...

You can't have a yoyo either, so you don't want to drop it too low. It's a classic control systems problem. An unstable system fluctuates violently. It's better to take a little extra recovery time and land more softly.

The only real question I see if how to calculate the difficulty on a retarget with less than 30 block. You can either just calculate since the last retarget, or you could use the last 30 actual blocks (taking the difficulty of each block into account), either one you could add some weight or just make them equal. Where is the source on github?