Pages:
Author

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

full member
Activity: 172
Merit: 100
I'm so proud to be a new member of the Noirbits community! Grin We're finally starting to get our sh** together.

I think that this is a quick summary of everything that has happened recently:

Now, I'm going to shut my big mouth. I'm going on radio silence until Noirbits hit 0.0001 BTC on Cryptsy. I'll see you all then!
full member
Activity: 172
Merit: 100
Working on getting a noirbits p2pool and blockexplorer running, will update with info in a couple hours.

Nice! I already sent a message to Gliss of Coinmarketcap so Noirbits can get relisted. I also posted a message on the main Coinmarketcap thread here: https://bitcointalk.org/index.php?topic=199685.420
full member
Activity: 140
Merit: 100
Working on getting a noirbits p2pool and blockexplorer running, will update with info in a couple hours.
full member
Activity: 172
Merit: 100
Hey Guys!

We need a working block explorer. This one is broken: http://nrb.webboise.com/chain/Noirbits Noirbits  is delisted from Coinmarketcap until this is fixed.

             
full member
Activity: 172
Merit: 100
NRB pool up and running.

nrb.nordicminers.eu

stratum+tcp://nrb.nordicminers.eu:9228


Prop, 1% fee.
Very nice! Grin
newbie
Activity: 51
Merit: 0
NRB pool up and running.

nrb.nordicminers.eu

stratum+tcp://nrb.nordicminers.eu:9228


Prop, 1% fee.
member
Activity: 76
Merit: 10
Hi all!

Could not connect to any of Noirbits pool Sad
Which settings will be the best for solo mining using wallet?
I mean Thread and Scantime?

Thanks!

newbie
Activity: 56
Merit: 0
Noirbits just added:

http://coinmarketcap.com/


Definitely a solid coin that's undervalued right now.

About to increase at least 10x
hero member
Activity: 532
Merit: 500
any nodes out there i only have one connection
legendary
Activity: 882
Merit: 1000
seems a lot has happened, let me read in and figure out the issue.
full member
Activity: 129
Merit: 100
I'm not quite sure I understand the problem, but let me suggest some stuff for the variation problem. I'm not a statistician, but it seems like 2 standard deviations from the mean is a good trigger. How about you take the last 30 samples, compute the mean and standard deviation. If the new sample is more than 2 standard deviations from the mean, then force a retarget. In a random process (as I remember it), >95% of samples should be within 2 standard deviations of the mean. That means that less than 5% of retargets would be from a random event, and 95% of the would be triggered by changes in hashing power.

^This!
member
Activity: 104
Merit: 10
I've actually implemented the algorithm but doesn't perform as well as expected with 30 blocks lookback. It however does no adjustments before block 30.

I ran it on testnet, and began with CPU mining at mininum difficulty, at about 9h30PM. I found 16 blocks in about 30 minutes, then kicked in some GPU power. So I multiplied the hasrate by a lot (I didn't note my CPU hashrate, so unfortunately I can't give the increase factor, but it was a lot, since I went from less than 100Khps to 4Mhps, let's say at least a 40x increase).

I managed to mine up to block 108, at around 0:00AM. So already, we were ~25 blocks of what should be expected (75 blocks) in 2.5 hours. I went to bed, at 8:00AM next morning, I was still at height 108. I was late for work, so I pointed my miners back to my pool, and left, unfortunately, not taking the time to see why it didn't mine anymore. But something definitely was not right. It was apparently my second instance that disconnected, stopping any further mining.

I need to run more tests with different lookback values. I will get back here when I've actually ran more tests and found the right balance. The issue is that with the variance involved in mining, it is really difficult to detect whether a low block time is due to luck or hashrate increase. It might be that a 10% variation is a too sensitive value for difficulty adjustments, so I also need to test with allowing a higher variation (15%, 20%, 25% ?) and combine it with different lookback values.

However, if I want to be efficient, I need to write test cases for that instead of being a lazy bum and test mining the algo... Cheesy

I'm not quite sure I understand the problem, but let me suggest some stuff for the variation problem. I'm not a statistician, but it seems like 2 standard deviations from the mean is a good trigger. How about you take the last 30 samples, compute the mean and standard deviation. If the new sample is more than 2 standard deviations from the mean, then force a retarget. In a random process (as I remember it), >95% of samples should be within 2 standard deviations of the mean. That means that less than 5% of retargets would be from a random event, and 95% of the would be triggered by changes in hashing power.
sr. member
Activity: 319
Merit: 250
I am not up to date with the current Algo for Noirbits, so take what I have to say with a grain of salt. This is mostly just my observations as a miner who watches the 30+ serious AltCoins that contend for top profitability on a daily basis...

As an example, BottleCaps, I don't know what their Algo for recalculations is, but they can handle multiple MultiPool types of hash power being dumped on them all at once, and it handles it without issue. It bounces back fairly quickly, and it has a decent steady following since it proved it can take the speed bumps well.

Can someone that knows a thing or two about the Algo's compare them with Noirbits?
full member
Activity: 154
Merit: 100
Ok, we got a big situation. Noirdice is forked all the way.

Pretty much every pool seems to be running on different chains....
full member
Activity: 154
Merit: 100
I've actually implemented the algorithm but doesn't perform as well as expected with 30 blocks lookback. It however does no adjustments before block 30.

I ran it on testnet, and began with CPU mining at mininum difficulty, at about 9h30PM. I found 16 blocks in about 30 minutes, then kicked in some GPU power. So I multiplied the hasrate by a lot (I didn't note my CPU hashrate, so unfortunately I can't give the increase factor, but it was a lot, since I went from less than 100Khps to 4Mhps, let's say at least a 40x increase).

I managed to mine up to block 108, at around 0:00AM. So already, we were ~25 blocks of what should be expected (75 blocks) in 2.5 hours. I went to bed, at 8:00AM next morning, I was still at height 108. I was late for work, so I pointed my miners back to my pool, and left, unfortunately, not taking the time to see why it didn't mine anymore. But something definitely was not right. It was apparently my second instance that disconnected, stopping any further mining.

I need to run more tests with different lookback values. I will get back here when I've actually ran more tests and found the right balance. The issue is that with the variance involved in mining, it is really difficult to detect whether a low block time is due to luck or hashrate increase. It might be that a 10% variation is a too sensitive value for difficulty adjustments, so I also need to test with allowing a higher variation (15%, 20%, 25% ?) and combine it with different lookback values.

However, if I want to be efficient, I need to write test cases for that instead of being a lazy bum and test mining the algo... Cheesy
member
Activity: 104
Merit: 10
If a block takes too long to find, diff. will automatically drop on next drop. If you look at the previous sequences I posted, the 30min. or more case will yield the following :

120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-1800 = 2.93 mn block average

Which is way above the 10% limit, triggering a diff. drop on next block.

What I'm gonna do this time is extract actual block times from the NRB chain, and use those as test cases for the new diff. algo, so we'll have concrete data to monitor the suggested change's impact on difficulty.
I agree. Retarget on every block, but use the last 30 to figure out the new value. That adds enough ballast to keep the system running smoothly, and also let's the difficulty go up with every block that's too fast, and go down with every block which is too slow. In the end the protection against hash spikes will be enough hashing power all the time to keep it stable.
full member
Activity: 154
Merit: 100
Ok, we'll need to add checkpoints also, it's been a while.

I'll let you handle that part. Changes are ready on my repo, I still need to test them so I won't be issuing a pull request yet.
legendary
Activity: 882
Merit: 1000
Ok, we'll need to add checkpoints also, it's been a while.
Pages:
Jump to: