John122
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 08:46:52 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 08:49:52 PM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 104
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 09:00:11 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 09:18:53 PM |
|
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](https://bitcointalk.org/Smileys/default/smiley.gif) The 80% cap would have the same effect though... if you think about it.
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 09:49:41 PM |
|
are we in concensus?
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 09:57:34 PM |
|
I think so... everyone ?
|
|
|
|
bahamapascal
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 10:24:38 PM |
|
Iam for taking it off of coinchoose untill the retargeting has bean modified, then put it back on as fast as possible ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 10:57:09 PM |
|
All right, thanks. I'm working on new diff rules as of now, almost done.
|
|
|
|
Breen2543
Newbie
Offline
Activity: 42
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 10:58:19 PM |
|
Noribits are dead, going absolutely no where, dont waste your time... geez lol. NEXT
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 11:02:00 PM |
|
Yeah I know, all altcoins are dead... but whatever.
|
|
|
|
TheRickTM
Newbie
Offline
Activity: 42
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 11:05:21 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 11:09:12 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2013, 11:19:38 PM Last edit: July 04, 2013, 01:16:08 AM by 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 02:42:48 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
oatmo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 104
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 04:20:39 PM |
|
Just kicked in another 3 miners to help get us over the hump.
|
|
|
|
oatmo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 104
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 05:44:16 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 06:21:57 PM |
|
Seems a bit too complex... the four hour retarget is to avoid killing the coin with massive hashrate drops.... look @ CHNCoin...
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 07:17:55 PM |
|
By the way, anyone here has the know-how to update makefiles ?
|
|
|
|
oatmo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 104
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 08:05:52 PM |
|
By the way, anyone here has the know-how to update makefiles ?
What do you need?
|
|
|
|
oatmo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 104
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2013, 08:13:52 PM |
|
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?
|
|
|
|
|