s4w3d0ff (OP)
Sr. Member
 Offline
Activity: 322
Merit: 250
Spray and Pray
|
 |
March 19, 2014, 12:53:46 AM |
|
The block finding time is now 60 sec (30 blocks found in 30 mins from block 64115 to 64145) so still not near the designed 40 sec.
The diff seems not to jump as high as before any more, but apparently still enough to cause some blocks to take several minutes to be found, slowing the average down quite a bit.
This will continue until the network hash gets a bit higher. Like I said before we had Kimotos Gravity Well before but there are exploits that involve nTime, until someone comes up with a better solution, the only thing that will stabilize the block time is more people mining. So spread the word! OK, I had the impression that the mining activity had already risen quite a bit, the pool I am on had mostly myself as contributor a couple days ago while this morning it had increased to more than 10% of the Network hashing rate (around 30Mh/s of almost 300Mh/s) so my contribution had shrunk to barely over 1% of the pool. I thought that to be a decent hash rate. Also, my understanding is that as long as the network hashing rate is constant, the diff does not change as jumps are mostly caused by changes in network hashing rate - which is a result of a profit switching pool... Without them, diff should be relatively constant unless it is very sensitive to block finding rate, which is a statistical and therefor noisy process by definition Now that almost all blocks carry around 0.3 CGA reward, there is no reason for pools to switch and I'd expected the block finding rate and the diff to stabilize. I see still large difference between actual block finding rate and design - for example the 40 blocks period from 64132 to 64172 took over an hour, so that is more than 1.5 minutes per block average, while the design is 40 sec. I didn't check the diff of the intermediate blocks but I am surprised that the finding time is more than 2x the designed value. I am not complaining, just pointing to possible areas to focus on in a next release - we'll have to accept that the mining will generate much less coins than we'd expect based on calculation - the payout should already be more smooth than before. To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so. |
|
|
|
|
|
|
|
|
The block chain is the main innovation of Bitcoin. It is the
first distributed timestamping system.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
Cor2
|
|
March 19, 2014, 01:40:40 AM |
|
To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s. So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s. However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease. Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time. |
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
March 19, 2014, 03:44:53 AM |
|
To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s. So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s. However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease. Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time. That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution. |
|
|
|
|
brother3
|
|
March 19, 2014, 06:09:30 AM |
|
Ok you two....Stop speaking Korean!!! I don't understand a damn thing...However, would you both kindly look at this post for a possible KGW-like solution? https://bitcointalk.org/index.php?topic=505243.0  To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s. So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s. However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease. Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time. That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution. |
|
|
|
|
omwtothemoon
Newbie
Offline
Activity: 50
Merit: 0
|
|
March 19, 2014, 09:12:46 AM |
|
Ok you two....Stop speaking Korean!!! I don't understand a damn thing...However, would you both kindly look at this post for a possible KGW-like solution? https://bitcointalk.org/index.php?topic=505243.0 To be honest the difficulty is more of less random. Even with a stable network hash rate you could find 2 blocks back to back in under 10 secs if very lucky. Since the re-target rate is so short the diff will make big jumps.The diff changes due to the time between blocks. So while one block was solved in 1 min and the next in 10 sec then the diff will do significant jumps. Where are you seeing the nethashrate being around 300Mhash? I haven't seen it go above 200Mhash in the last week or so.
Now that I think about it longer, it may have been that I saw a network hash rate of 210 or 220Mh/s with the pool doing over 25Mh/s. So you are confirming that the diff calculation is very sensitive to the last block finding time, which is a random process of luck, so that as a result the diff will jump around and the block finding time might increase or decrease, but since the max decrease is 40 sec below designed (40 sec) while the maximum increase is extremely large (minutes or hours), the result of jumping diff is a much higher average block finding time, since (for example) at a standard diff of 3 a block may suddenly be found after 5 seconds so in 1/8 of designed time, which could lead the re-target algorithm to simply (erroneously) multiply the diff by 8 in an attempt to get the next block find time 8 times 5s. However, since the diff of 3 was actually giving an avg 40s block finding time and it was luck that a block was found after 5s, the new diff of 3x8 = 24 will result in an average block finding time of 8x40s = 5 min 20s. Hence, the upward correction of diff should be dampened to avoid these overshoots, since a higher diff causes much more time increase than lower diffs causes time decrease. Since a switching pool that turns on and off on a per-block basis cannot be prevented with a diff that is calculated before the block starts, there is no reason to make a very aggressive "attack" (increase) of diff that will just hurt all steady miners by a much higher block finding time. So, it is better to dampen the diff to respond reasonable fast to sudden hash rate changes (within a couple retargets) but there is no need to re-target to a completely new value every time. For example, the diff could be limited to change no more than doubling or halving during retarget, which will still allow a very large change in a few steps, but not the large jumps we have seen. If the concern is to quickly recover from a major drop in network hash rate, then the re-target algorithm could make an exception for a long time since last block found to re-target fresh immediately, while when block are found regularly to use a more smooth re-target. Reducing jumps will allow the avg block find time to be closed to the designed 40s time. That is what Kimotos Gravity Well did/does... but have yet to figure out a better solution. +1 for bringing that up! I have no idea what it says however lol:p |
|
|
|
|
Miner538
Newbie
Offline
Activity: 43
Merit: 0
|
|
March 19, 2014, 10:35:44 AM |
|
I am mining this coin for a while and I am happy to see the rewards being payout more often.
This will attract more miners along the way. DEV your the best!
+1 for all the effort
|
|
|
|
|
|
|
|
tertius993
|
|
March 19, 2014, 11:06:06 AM |
|
I notice the exchanges still have the old logo - have they been asked to change?
|
|
|
|
|
|
|
|
brother3
|
|
March 19, 2014, 03:05:19 PM |
|
Voted... We are # 2 right now |
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
March 19, 2014, 06:03:44 PM |
|
Nice find! Unfortunately the proposed fix can still be exploited to a "time traveling attack". They seem to be working it out in that thread so I will keep my eyes on it.  |
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
March 19, 2014, 06:06:09 PM |
|
I notice the exchanges still have the old logo - have they been asked to change?
Not yet. I will be sending emails today. |
|
|
|
|
cdboot
|
|
March 19, 2014, 06:12:15 PM |
|
|
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
March 19, 2014, 06:13:19 PM |
|
Awesome! thank you! Trying to figure out where to put this link... I guess make a Coin Database section... |
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
March 19, 2014, 06:16:37 PM |
|
|
|
|
|
|
Cor2
|
|
March 20, 2014, 12:45:52 AM |
|
Nice find! Unfortunately the proposed fix can still be exploited to a "time traveling attack". They seem to be working it out in that thread so I will keep my eyes on it. Brother3, LOL - thanks for the find! I made a suggestion to that thread for a new and simple algorithm that should remove the complexity and time travel issues of KGW and if we use it for CGA, it will quieten the jumps in the diff by averaging the block find time so that luck and sudden increases do not make it jump around. |
|
|
|
forzendiablo
Legendary
Offline
Activity: 1526
Merit: 1000
the grandpa of cryptos
|
|
March 20, 2014, 12:46:29 AM |
|
luving this coin!
|
yolo
|
|
|
awesomeperson451
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 20, 2014, 03:11:23 AM
Last edit: March 20, 2014, 03:23:32 AM by awesomeperson451 |
|
shit.... Tried to make some extra money selling cross market at a profit.... bought 10 CGA for .0031 BTC each, then tried to sell them on allcrypt at .0041 each, or so I thought.... ended up selling 10 cga at .00041 BTC each... I was wondering why no one tried that yet...
I guess it's about time I get new contacts.
|
|
|
|
|
s4w3d0ff (OP)
Sr. Member
Offline
Activity: 322
Merit: 250
Spray and Pray
|
|
March 20, 2014, 03:18:56 AM |
|
shit.... Tried to make some extra money selling cross market at a profit.... bought 10 CGA for .0031 BTC each, then tried to sell them on allcoin at .0041 each, or so I thought.... ended up selling 10 cga at .00041 BTC each... I was wondering why no one tried that yet...
I guess it's about time I get new contacts.
 got to count those zeros! I almost sold 8 CGA at 0.0006 on Allcrypt! |
|
|
|
|
cdboot
|
|
March 20, 2014, 03:36:05 AM |
|
shit.... Tried to make some extra money selling cross market at a profit.... bought 10 CGA for .0031 BTC each, then tried to sell them on allcoin at .0041 each, or so I thought.... ended up selling 10 cga at .00041 BTC each... I was wondering why no one tried that yet...
I guess it's about time I get new contacts.
got to count those zeros! I almost sold 8 CGA at 0.0006 on Allcrypt! After Block 64k, becomes very difficult mining |
|
|
|
|
|
