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

I'm so proud to be a new member of the Noirbits community! We're finally starting to get our sh** together.

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

• Diatonic has fixed the block explorer @http://nrb.webboise.com/chain/Noirbits. Please feel free to tip him at DtFbXr8ykWwbnBxdNKpXhqCtYqyCT6fFis
• A message has been sent to Gliss of Coinmarketcap to relist us Noirbits are relisted: http://coinmarketcap.com/.
• Educatedwarrior has made contact with our fearless leader Barwizi. All is well, and he is hard at work improving Noirbits (improved version to be released soon).
• TheRickTM has been contacted. He is working on updating http://www.noirbits.com/
  
• We have at least 3 fully functioning pools: http://nrb.cryptoculture.net, http://nrb.cryptopools.com, and http://noir.minepool.net/. We also have the original Noirbits site as a powerful resource: http://com-http.us/ccdir/nrb/.

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!

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

Working on getting a noirbits p2pool and blockexplorer running, will update with info in a couple hours.

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.

             

Very nice!

NRB pool up and running.

nrb.nordicminers.eu

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

Prop, 1% fee.

Hi all!

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

Thanks!

Noirbits just added:

http://coinmarketcap.com/


Definitely a solid coin that's undervalued right now.

About to increase at least 10x

https://bitcointalksearch.org/topic/ann-noirbits-takeover-update-v2250-fixes-sync-issue-270264

any nodes out there i only have one connection

seems a lot has happened, let me read in and figure out the issue.

^This!

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.

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?

See https://bitcointalksearch.org/topic/ann-noirbits-takeover-update-v2250-fixes-sync-issue-270264 for a fix to the fork.

Ok, we got a big situation. Noirdice is forked all the way.

Pretty much every pool seems to be running on different chains....

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

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.

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.

Ok, we'll need to add checkpoints also, it's been a while.