Aaed
Newbie
 Offline
Activity: 20
Merit: 0
|
 |
August 01, 2013, 12:35:37 PM |
|
This morning there was a 0.4 diff.
Then it went on top of CoinChoose, 5 seconds later we have a 10.11 diff which is lasting hours and automatic pools guys gone far away xD.
|
|
|
|
|
|
John122
|
|
August 04, 2013, 04:37:41 AM |
|
I've got a question about the upcoming update. Will we fork to the new version soon after the release of the updated client or will we wait another week before doing so? Also, any news about NoirDice or Noirbank?  |
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
August 04, 2013, 05:57:59 AM |
|
Noirbank is stagnant due to waiting on paperwork. As for the retarget i have decided to set a block target 3 cycles away from when i push. What i am trying to get right is the quick drop in diff.
|
|
|
|
|
|
stbgefltc
|
|
August 04, 2013, 03:06:54 PM
Last edit: August 04, 2013, 03:39:55 PM by stbgefltc |
|
Well, finally ! Noirdice is up & running, running bets on 0 confirmations, so you get instant results You can give it a try @ http://www.noirdice.comPlease note the site is still in beta phase, I will be monitoring bugs & so on... Any and all feedback is welcome. |
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
August 04, 2013, 03:20:16 PM |
|
great work, now jus need to adjust the diff, i was thinking of either a per block adj or else a 5 block adj with immediate rises to match hash rate.
|
|
|
|
|
|
John122
|
|
August 04, 2013, 05:09:01 PM |
|
Well, finally ! Noirdice is up & running, running bets on 0 confirmations, so you get instant results Nice job! We're gonna need a higher "max bet" cap, but I'm guessing it is only this low for beta purposes.  |
|
|
|
|
|
stbgefltc
|
|
August 04, 2013, 05:12:14 PM |
|
Well, finally ! Noirdice is up & running, running bets on 0 confirmations, so you get instant results Nice job! We're gonna need a higher "max bet" cap, but I'm guessing it is only this low for beta purposes. Yeah, I will increase them once I'm sure everything rolls smoothly. I've ran a lot of tests, but you can never be too sure. PS. Sorry for the design, but it's *really* not my area of expertise... |
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
August 04, 2013, 05:25:49 PM |
|
Well, finally ! Noirdice is up & running, running bets on 0 confirmations, so you get instant results Nice job! We're gonna need a higher "max bet" cap, but I'm guessing it is only this low for beta purposes. Yeah, I will increase them once I'm sure everything rolls smoothly. I've ran a lot of tests, but you can never be too sure. PS. Sorry for the design, but it's *really* not my area of expertise... For a start it's great , i'm thinking of applying new rules @ block 33333. any ideas? |
|
|
|
|
|
stbgefltc
|
|
August 05, 2013, 07:39:13 AM |
|
Gonna work on that as soon as I can...
Also, on another issue, I think fees are way too high. If you look at Bitcoin, min. fees are 0.001 BTC for non-free transactions. With Noirdice, we're at 0.1 NRB for non-free transaction. So basically, NRB transaction are 100x more expensive than BTC. I think we should lower them to 0.001 NRB to encourage NRB transactions.
The change could be included with the upcoming difficulty rules to ensure everyone gets those changes at the same time...
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
August 05, 2013, 07:52:48 AM |
|
Gonna work on that as soon as I can...
Also, on another issue, I think fees are way too high. If you look at Bitcoin, min. fees are 0.001 BTC for non-free transactions. With Noirdice, we're at 0.1 NRB for non-free transaction. So basically, NRB transaction are 100x more expensive than BTC. I think we should lower them to 0.001 NRB to encourage NRB transactions.
The change could be included with the upcoming difficulty rules to ensure everyone gets those changes at the same time...
agreed, what do you think of the 5 block retarget? |
|
|
|
|
|
stbgefltc
|
|
August 05, 2013, 08:20:32 AM |
|
Gonna work on that as soon as I can...
Also, on another issue, I think fees are way too high. If you look at Bitcoin, min. fees are 0.001 BTC for non-free transactions. With Noirdice, we're at 0.1 NRB for non-free transaction. So basically, NRB transaction are 100x more expensive than BTC. I think we should lower them to 0.001 NRB to encourage NRB transactions.
The change could be included with the upcoming difficulty rules to ensure everyone gets those changes at the same time...
agreed, what do you think of the 5 block retarget? Not too fond of the idea. I think evaluating retarget at every block is a smoother move : it gives the block chain the opportunity to recover from hashrates spikes as soon as they are gone, and inversely, to raise difficulty as soon as hashrate spikes (like, when a multipool kicks in). Retargetting every 5 blocks is too short if you only look back 5 blocks, you need to take variance into account. The core idea is not to lower the count of blocks used to evaluate difficulty, but rather to evaluate retarget at every block, by looking back at the last 30 blocks and the time it took to find them. So when a hashrate spike comes along, the next block is going to be found way too fast. Difficulty might rise just a little bit, or not at all. But on second block after spike starts, it will rise just a bit more. And so on... Assuming we have a stable 2 minute block time before a spike that brings block time down to 10s, you'll have this sequence going on for block times : 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-120 = 2mn avg 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-10 = 1.93mn avg 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-10-10 = 1.87mn avg 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-10-10-10 = 1.81mn avg .... And so on... if you don't retarget. But if you retarget everytime the 30 block average time is off, by say +/-10%, you'll be forcing retarget by 3 block. Diff won't rise as much, but it will rise. The same will be true the other way around, but we won't reach situations where spikes leave diff. way too high. The previous difficulty fix had a bug, but it still proved useful. Difficulty was left by a spike @ 10 at one point. By next block, which took more than four hours to find, diff. dropped back to 6. I didn't monitor what went on afterwards, and don't remember the block height, but it shows that this is a good starting point. What we really need to avoid is massive difficulty variations, they penalize loyal miners and encourage coin hoppers, who only come back when diff. has dropped back to looow values thanks to the backing of loyal miners. |
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
August 05, 2013, 08:33:16 AM |
|
So per block target it is, but sometimes diff may rise to the point that 30 min go by without a block solved....should we leave it like that or adjust the time to force diff dwn after a certain time period. ?
|
|
|
|
|
|
stbgefltc
|
|
August 05, 2013, 08:38:00 AM |
|
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.
|
|
|
|
barwizi (OP)
Legendary
Offline
Activity: 882
Merit: 1000
|
|
August 05, 2013, 08:53:01 AM |
|
Ok, we'll need to add checkpoints also, it's been a while.
|
|
|
|
|
|
stbgefltc
|
|
August 05, 2013, 05:46:42 PM |
|
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. |
|
|
|
oatmo
Member
Offline
Activity: 104
Merit: 10
|
|
August 08, 2013, 06:22:21 AM |
|
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. |
|
|
|
|
|
stbgefltc
|
|
August 08, 2013, 05:17:17 PM
Last edit: August 08, 2013, 07:13:13 PM by stbgefltc |
|
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...  |
|
|
|
|
stbgefltc
|
|
August 08, 2013, 06:03:40 PM |
|
Ok, we got a big situation. Noirdice is forked all the way.
Pretty much every pool seems to be running on different chains....
|
|
|
|
|
|
|
Jazkal
|
|
August 08, 2013, 10:19:54 PM |
|
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?
|
|
|
|
|
|
