digitalindustry
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2013, 10:59:39 AM |
|
also happy to design a Advert for Norbits mate as per discussion - if you want to do a giveaway or something ? send me some images and i'll make it if you like , but tell me, or point me to a little bit more about the Currency for example what's the name mean?
|
- Twitter @Kolin_Quark
|
|
|
moltenmich
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2013, 11:16:42 AM |
|
Man, I haven't been keeping up with this thread. Caught up now! Good job on this guys!
|
█ Professional Design & Multimedia █
michpalmer.com
|
|
|
TheRickTM
Newbie
Offline
Activity: 42
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 01, 2013, 07:45:29 PM |
|
With the current spikes in hash rate due to us being on an exchange now I wonder if it would be possible to implement something like mini-retargets. These would be different than the normal hourly retarget that adjusts the difficulty based on the current network strength every 30 blocks. Feather coin not to long ago experienced the same issues where their difficulty went so high that everyone dropped out and the 3 day retarget turned into 30. So if we had these network checkpoints every 5 or 10 blocks that could adjust the difficulty by a maximum of 33% each it would allow the network to get back to a stable difficulty quicker 3-6 times quicker. We currently retarget around every 60 minutes but at times it is going up to every 3-4 hours now dropping the hash rate to single digits which make the network really unsafe. Just a suggestion, anyone know the drawbacks or technical difficulties of implementing this?
|
|
|
|
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 01, 2013, 08:39:28 PM |
|
With the current spikes in hash rate due to us being on an exchange now I wonder if it would be possible to implement something like mini-retargets. These would be different than the normal hourly retarget that adjusts the difficulty based on the current network strength every 30 blocks. Feather coin not to long ago experienced the same issues where their difficulty went so high that everyone dropped out and the 3 day retarget turned into 30. So if we had these network checkpoints every 5 or 10 blocks that could adjust the difficulty by a maximum of 33% each it would allow the network to get back to a stable difficulty quicker 3-6 times quicker. We currently retarget around every 60 minutes but at times it is going up to every 3-4 hours now dropping the hash rate to single digits which make the network really unsafe. Just a suggestion, anyone know the drawbacks or technical difficulties of implementing this?
Or alternatively, if you had 4 hours without a retarget, then you retarget on the next block, something like that.
|
|
|
|
TheRickTM
Newbie
Offline
Activity: 42
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 02:13:43 AM |
|
It also looks that there is an issue with the way that the network hash is being calculated. We will need to look into that as it is not representing the true network hash rate over few enough blocks. It is showing that our pools have over 100% of the network when they clearly don't, and it also is dropping the difficulty even when the true hashrate is higher.
|
|
|
|
cyberkiller
Newbie
Offline
Activity: 43
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 04:02:24 AM |
|
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 04:49:35 AM |
|
It also looks that there is an issue with the way that the network hash is being calculated. We will need to look into that as it is not representing the true network hash rate over few enough blocks. It is showing that our pools have over 100% of the network when they clearly don't, and it also is dropping the difficulty even when the true hashrate is higher.
Understood, i will look into it and we should be good to go in a bit.
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 07:03:42 AM |
|
It also looks that there is an issue with the way that the network hash is being calculated. We will need to look into that as it is not representing the true network hash rate over few enough blocks. It is showing that our pools have over 100% of the network when they clearly don't, and it also is dropping the difficulty even when the true hashrate is higher.
Understood, i will look into it and we should be good to go in a bit. Line 323 of bitcoinrpc.cpp : if (lookup <= 0) lookup = pindexBest->nHeight % 2016 + 1; The 2016 is leftover from litecoind ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) So basically hashrate is calculated over the last 2016 blocks which spans way too many diff retargets in Noirbits... If you want, I can push a fix tonight when I get home from work.
|
|
|
|
MarKusRomanus
Legendary
Offline
Activity: 910
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 07:04:51 AM |
|
New NoirBits Stratum mining pool, noir.minepool.netProportional payout per block (not PPLNS) by share ratio , finder gets 5% of the block off the top.
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 08:07:14 AM |
|
It also looks that there is an issue with the way that the network hash is being calculated. We will need to look into that as it is not representing the true network hash rate over few enough blocks. It is showing that our pools have over 100% of the network when they clearly don't, and it also is dropping the difficulty even when the true hashrate is higher.
Understood, i will look into it and we should be good to go in a bit. Line 323 of bitcoinrpc.cpp : if (lookup <= 0) lookup = pindexBest->nHeight % 2016 + 1; The 2016 is leftover from litecoind ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) So basically hashrate is calculated over the last 2016 blocks which spans way too many diff retargets in Noirbits... If you want, I can push a fix tonight when I get home from work. ok, lets work together on it then. By the way, whoever sent me the 300 Noir, thank you very much. I am currently beta testing a bot that trades on cryptsy and btce at the same time so any old coins you have lying around would be appreciated. Currently it's making an average 3% profit daily.
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 08:12:54 AM |
|
ok, lets work together on it then. By the way, whoever sent me the 300 Noir, thank you very much. I am currently beta testing a bot that trades on cryptsy and btce at the same time so any old coins you have lying around would be appreciated. Currently it's making an average 3% profit daily.
What's the address ? If you mined on miners-united.com, it's probably from there. Some blocks were not getting paid, so I setup a new routine to fix that, and everyone who ever mined must have gotten some extra coins (there were about 10K Noirs to payout) this morning... so enjoy ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) For the client, I don't know the source code very well, but we need to find a way to get the last blocks that have the same difficulty as the current diff, since the hashrate formula is based off current difficulty.
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 08:59:50 AM |
|
Ok, I got it, if you can push the diff (and test it...), if you can't, I'll get to it tonight CEST : bitcoinrpc.cpp line 323 should be : lookup = pindexBest->nHeight % 60 + 1; Well, not exactly, but it should better than now (technically, target is recalculated every 60 blocks (see main.cpp lines 838 and 870) and not every hour or two hours, since it assumes that a block lasts 2minutes)... Until we get a better algo to recalc target, 60 should be close enough... Until then, I doubt diff will drop since over the last 2016 blocks, we've had some very low diffs with very low block times, which is giving us way out of scale hashrates... But I could be mistaken, since as I mentionned before, I don't know the source code very well...
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 11:29:11 AM |
|
coinmine down?
|
|
|
|
feeleep
Legendary
Offline
Activity: 1197
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 11:46:57 AM |
|
coinmine down?
bloody eloipool... I came back to stratum + pushpoold now.
|
|
|
|
whitepaint0909
Newbie
Offline
Activity: 46
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 11:49:57 AM |
|
It stoped paying out at around 1-2am last night according to my miners. nrb.coinmine.pl that is.
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 11:52:05 AM |
|
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...
|
|
|
|
feeleep
Legendary
Offline
Activity: 1197
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 11:58:49 AM |
|
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...
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 11:59:29 AM |
|
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.
|
|
|
|
stbgefltc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 12:02:25 PM Last edit: July 02, 2013, 12:37:40 PM by stbgefltc |
|
Sure thing, but lunch's over ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) 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
|
|
|
|
JDDev
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 02, 2013, 12:50:17 PM |
|
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.
|
|
|
|
|