Come and try my Luckycoin pool: http://lky.nordicminers.eu, Stratum/PPLNS/1% Fee/No delays in payouts.
stratum+tcp://lky.nordicminers.eu:9441
stratum+tcp://lky.nordicminers.eu:9441
Great! Thank you!
Titan
Topic: [ANN] LuckyCoin LKY | Lucky Blocks | Fast | Fun | Fair - page 8. (Read 113235 times)
Great! Thank you!
Titan
Come and try my Luckycoin pool: http://lky.nordicminers.eu, Stratum/PPLNS/1% Fee/No delays in payouts.
stratum+tcp://lky.nordicminers.eu:9441
stratum+tcp://lky.nordicminers.eu:9441
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
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.
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
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
...
The Luckycoin QT windows client is now available on GitHub.
https://github.com/LuckyCoinFoundation/LuckycoinQT
https://bitcointalksearch.org/topic/annlky-luckycoin-security-update-236714
https://github.com/LuckyCoinFoundation/LuckycoinQT
https://bitcointalksearch.org/topic/annlky-luckycoin-security-update-236714
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
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.
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
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
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.
Have a read of the last few pages in these threads and you will know why:
https://bitcointalk.org/index.php?topic=231524.480
https://bitcointalk.org/index.php?topic=167635.1320
another thanks owed to multipool?
Maybe retarget in 4 hours actual time instead of block time? I'd rather have the difficulty constantly readjust then what we have now.
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?
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.
New security update for the Luckycoin network:
https://bitcointalksearch.org/topic/annlky-luckycoin-security-update-236714
Titan
https://bitcointalksearch.org/topic/annlky-luckycoin-security-update-236714
Titan
Update your clients people!
just set up the luckycoin pool at https://lky.epools.org
everything as usual: 1.5% pool fee, PPLNS & stability
drop in, help to spread the hash rate!
everything as usual: 1.5% pool fee, PPLNS & stability
drop in, help to spread the hash rate!
New security update for the Luckycoin network:
https://bitcointalksearch.org/topic/annlky-luckycoin-security-update-236714
Titan
https://bitcointalksearch.org/topic/annlky-luckycoin-security-update-236714
Titan
Steadily above .00003 on cryptsy. If no one noticed. 
Jump to: