|
rapta
|
 |
July 14, 2013, 03:26:19 AM |
|
The flash miners have killed mining this coin. Difficulty changes are taking days since it's taking forever to find blocks with so little network hash power. Does this coin need a hard fork with different difficult adjustment code to stay alive?
|
|
|
|
|
|
rapta
|
|
July 14, 2013, 03:27:23 AM |
|
Maybe retarget in 4 hours actual time instead of block time? I'd rather have the difficulty constantly readjust then what we have now.
|
|
|
|
|
|
nearmiss
|
|
July 14, 2013, 03:35:46 AM |
|
another thanks owed to multipool?
|
Profit-Switching Pool w/ Vardiff -> http://hashco.ws Optionally keep the alts we mine or auto-trade for BTC. In addition can be paid out in any of: 365, AC, BC, BTC, C2, CINNI, COMM, FAC, HBN, MINT, PMC, QRK, RDD, WC, XBC |
|
|
|
|
|
Titan
|
|
July 15, 2013, 01:49:21 AM
Last edit: July 15, 2013, 02:25:33 AM by Titan |
|
Why has the difficulty stayed so high? The network has rate is pretty low. Based on 1 minute blocks we should be near block 65,500 and are only on 54,204 as of this post.
We are getting an excessive amount of hashing power from the coinchoose/coinwarz crowd after a retarget. It took us close to 400MH/s yesterday and over 400MH/s today with spikes over 1GH/s! It's like an 10x increase from the baseline hashing power of the network. On the other hand one can still get a decent amount of coins during the time of high difficulty because the effective hash rate is quite low during these times. The algorithm for the hashrate calculation takes an average over many blocks. So it's always a slow up and down. The retarget times are still around 24 hours, that is still acceptable in this situation, imo. An effective way to fight the flash mining crowd is the keep the hashing rate high during the time of high difficulty. This then decreases the relative amount of coins the flash miners can get and thus the attractiveness of flash mining the coin. Titan |
|
|
|
|
|
Titan
|
|
July 15, 2013, 01:59:34 AM |
|
Maybe retarget in 4 hours actual time instead of block time? I'd rather have the difficulty constantly readjust then what we have now.
I will review this issue again. The retarget is bound to the blocks to keep the network in sync. A very low block count to retarget might indeed help. Titan |
|
|
|
|
|
rapta
|
|
July 16, 2013, 02:50:04 AM |
|
Sadly it's only getting worse. We are beyond a 24 hour retarget at this point. Even 24 hours is bad, because in reality all that means is that only 480 blocks are mined for each retarget period (~2 days right now). That's quite a bit shy of the target 1440 blocks that are supposed to be created each day.
|
|
|
|
|
|
Titan
|
|
July 16, 2013, 10:38:53 AM |
|
Sadly it's only getting worse. We are beyond a 24 hour retarget at this point. Even 24 hours is bad, because in reality all that means is that only 480 blocks are mined for each retarget period (~2 days right now). That's quite a bit shy of the target 1440 blocks that are supposed to be created each day.
Yes, some action is required here. I am researching the best retarget times now. So not to introduce other undesired side effects. I am thinking now of 5 - 10 min retarget intervals. So we will do a hard fork in the near future to break this feedback cycle. Titan |
|
|
|
|
|
Titan
|
|
July 16, 2013, 11:44:39 PM |
|
|
|
|
|
|
|
erk
|
|
July 17, 2013, 12:07:28 AM
Last edit: July 17, 2013, 12:21:06 AM by erk |
|
Sadly it's only getting worse. We are beyond a 24 hour retarget at this point. Even 24 hours is bad, because in reality all that means is that only 480 blocks are mined for each retarget period (~2 days right now). That's quite a bit shy of the target 1440 blocks that are supposed to be created each day.
Yes, some action is required here. I am researching the best retarget times now. So not to introduce other undesired side effects. I am thinking now of 5 - 10 min retarget intervals. So we will do a hard fork in the near future to break this feedback cycle. Titan See if you can re-target based on time rather than block count, it should be pretty easy to do as each block has a timestamp so an "if greater than timestamp = x then adjust". Most devs take the easy way out and just change the block count parameter because it's easier to calculate when the last change occured, but just look at all the coins that have been high diff locked by the flash mining crowd to see that's pretty hopeless. I think an elapsed time diff adjustment, like 10min, 30min, 1hr or more should be good, just depends on how long you are prepared to leave the block rate out of range. If you adjust frequently, say every 10min, then you could set a limit like no more than +/- 10% change every 10min. So the ups and downs are a bit more graceful. If you went time based adjustments ask people to nominate the interval and the percentage to see whats prefered. You could even run a poll with some choices to see what miners want. eg. Interval Max diff adjustment 10min 10% 30min 50% 60min unlimited ... |
|
|
|
|
|
Titan
|
|
July 17, 2013, 01:42:55 AM
Last edit: July 17, 2013, 02:20:47 AM by Titan |
|
Sadly it's only getting worse. We are beyond a 24 hour retarget at this point. Even 24 hours is bad, because in reality all that means is that only 480 blocks are mined for each retarget period (~2 days right now). That's quite a bit shy of the target 1440 blocks that are supposed to be created each day.
Yes, some action is required here. I am researching the best retarget times now. So not to introduce other undesired side effects. I am thinking now of 5 - 10 min retarget intervals. So we will do a hard fork in the near future to break this feedback cycle. Titan See if you can re-target based on time rather than block count, it should be pretty easy to do as each block has a timestamp so an "if greater than timestamp = x then adjust". Most devs take the easy way out and just change the block count parameter because it's easier to calculate when the last change occured, but just look at all the coins that have been high diff locked by the flash mining crowd to see that's pretty hopeless. I think an elapsed time diff adjustment, like 10min, 30min, 1hr or more should be good, just depends on how long you are prepared to leave the block rate out of range. If you adjust frequently, say every 10min, then you could set a limit like no more than +/- 10% change every 10min. So the ups and downs are a bit more graceful. If you went time based adjustments ask people to nominate the interval and the percentage to see whats prefered. You could even run a poll with some choices to see what miners want. eg. Interval Max diff adjustment 10min 10% 30min 50% 60min unlimited ... I see your point now. This is an interesting idea. There might be a problem if consecutive block numbers do not have consecutive time stamps. I have to think a bit about it. Certainly I am open to new ideas from the community to make the network more robust and secure and give a fair share to all miners. Titan |
|
|
|
|
|
flound1129
|
|
July 17, 2013, 02:52:06 AM |
|
Sadly it's only getting worse. We are beyond a 24 hour retarget at this point. Even 24 hours is bad, because in reality all that means is that only 480 blocks are mined for each retarget period (~2 days right now). That's quite a bit shy of the target 1440 blocks that are supposed to be created each day.
Yes, some action is required here. I am researching the best retarget times now. So not to introduce other undesired side effects. I am thinking now of 5 - 10 min retarget intervals. So we will do a hard fork in the near future to break this feedback cycle. Titan See if you can re-target based on time rather than block count, it should be pretty easy to do as each block has a timestamp so an "if greater than timestamp = x then adjust". Most devs take the easy way out and just change the block count parameter because it's easier to calculate when the last change occured, but just look at all the coins that have been high diff locked by the flash mining crowd to see that's pretty hopeless. I think an elapsed time diff adjustment, like 10min, 30min, 1hr or more should be good, just depends on how long you are prepared to leave the block rate out of range. If you adjust frequently, say every 10min, then you could set a limit like no more than +/- 10% change every 10min. So the ups and downs are a bit more graceful. If you went time based adjustments ask people to nominate the interval and the percentage to see whats prefered. You could even run a poll with some choices to see what miners want. eg. Interval Max diff adjustment 10min 10% 30min 50% 60min unlimited ... I see your point now. This is an interesting idea. There might be a problem if consecutive block numbers do not have consecutive time stamps. I have to think a bit about it. Certainly I am open to new ideas from the community to make the network more robust and secure and give a fair share to all miners. Titan You may want to look at Mincoin's diff adjustment. It handles the hashrate bursts rather well. |
Multipool - Always mine the most profitable coin - Scrypt, X11 or SHA-256!
|
|
|
Hippie Tech
aka Amenstop
Legendary
 Offline
Activity: 1624
Merit: 1001
All cryptos are FIAT digital currency. Do not use.
|
|
July 18, 2013, 03:47:56 AM |
|
Sadly it's only getting worse. We are beyond a 24 hour retarget at this point. Even 24 hours is bad, because in reality all that means is that only 480 blocks are mined for each retarget period (~2 days right now). That's quite a bit shy of the target 1440 blocks that are supposed to be created each day.
Yes, some action is required here. I am researching the best retarget times now. So not to introduce other undesired side effects. I am thinking now of 5 - 10 min retarget intervals. So we will do a hard fork in the near future to break this feedback cycle. Titan See if you can re-target based on time rather than block count, it should be pretty easy to do as each block has a timestamp so an "if greater than timestamp = x then adjust". Most devs take the easy way out and just change the block count parameter because it's easier to calculate when the last change occured, but just look at all the coins that have been high diff locked by the flash mining crowd to see that's pretty hopeless. I think an elapsed time diff adjustment, like 10min, 30min, 1hr or more should be good, just depends on how long you are prepared to leave the block rate out of range. If you adjust frequently, say every 10min, then you could set a limit like no more than +/- 10% change every 10min. So the ups and downs are a bit more graceful. If you went time based adjustments ask people to nominate the interval and the percentage to see whats prefered. You could even run a poll with some choices to see what miners want. eg. Interval Max diff adjustment 10min 10% 30min 50% 60min unlimited ... I see your point now. This is an interesting idea. There might be a problem if consecutive block numbers do not have consecutive time stamps. I have to think a bit about it. Certainly I am open to new ideas from the community to make the network more robust and secure and give a fair share to all miners. Titan You may want to look at Mincoin's diff adjustment. It handles the hashrate bursts rather well. Or.. you could.. as a courtesy, to each coin's core movement, decide that coin hopping is BAD BUSINESS. HT xD |
|
|
|
nordicminers
Newbie
Offline
Activity: 51
Merit: 0
|
|
July 18, 2013, 09:44:50 AM |
|
Come and try my Luckycoin pool: http://lky.nordicminers.eu, Stratum/PPLNS/1% Fee/No delays in payouts. stratum+tcp://lky.nordicminers.eu:9441 |
|
|
|
|
|
Titan
|
|
July 19, 2013, 12:58:48 AM |
|
Come and try my Luckycoin pool: http://lky.nordicminers.eu, Stratum/PPLNS/1% Fee/No delays in payouts. stratum+tcp://lky.nordicminers.eu:9441 Great! Thank you! Titan |
|
|
|
|
|
rapta
|
|
July 21, 2013, 05:29:40 AM |
|
Titan, how is the difficulty fix coming?
|
|
|
|
|
|
Titan
|
|
July 22, 2013, 05:36:02 AM |
|
Titan, how is the difficulty fix coming?
I have analyzed the Mincoin algorithm. It went form a 4x/4x to a 2x/8x configuration. So the difficulty cannot rise as fast as before (2x) and it drops more quickly (8x). This makes sense in some situations and we can also go into that direction. I am still researching the other parameters. We certainly want to avoid a situation like Craftcoin. Titan |
|
|
|
|
|
Lohoris
|
|
July 22, 2013, 10:12:41 AM |
|
Titan, how is the difficulty fix coming?
I have analyzed the Mincoin algorithm. It went form a 4x/4x to a 2x/8x configuration. So the difficulty cannot rise as fast as before (2x) and it drops more quickly (8x). This makes sense in some situations and we can also go into that direction. I am still researching the other parameters. We certainly want to avoid a situation like Craftcoin. Titan You could add some clause like testnet, such as "if no block at all is found in X minutes, difficulty immediately drops to Y". Has this already been tested in a living coin? |
|
|
|
|
Titan
|
|
July 22, 2013, 11:05:24 AM |
|
Titan, how is the difficulty fix coming?
I have analyzed the Mincoin algorithm. It went form a 4x/4x to a 2x/8x configuration. So the difficulty cannot rise as fast as before (2x) and it drops more quickly (8x). This makes sense in some situations and we can also go into that direction. I am still researching the other parameters. We certainly want to avoid a situation like Craftcoin. Titan You could add some clause like testnet, such as "if no block at all is found in X minutes, difficulty immediately drops to Y". Has this already been tested in a living coin? This causes a synchronization issue. Think about a block that is found exactly at the cutoff time. The chain would fork and the question is who has the right chain now. |
|
|
|
|
|
Titan
|
|
July 22, 2013, 11:42:34 AM |
|
Community Poll
Dear Luckycoin Community,
One way to cure the current difficulty fluctuations on the Luckycoin network is to go to the root cause and ask for a suspension or removal of LKY from multipool.in.
My investigations have shown that essentially all the 400MH/s we see after a retarget come from the multipool site.
This measure would give back the real supporters of the Luckycoin network the opportunity to mine their fair share of coins.
Please post your opinion regarding this measure.
Titan
|
|
|
|
|
|
