Good point to consider! Thanks for the feedback! We will look at that more in depth.

We are not opposed to any videos people make promoting DigiByte in a positive manner! Looks fine to us!

Thank you for taking the time to put it together!

Any other promotional material you put together is much appreciated. Feel free to use any of the DigiByte logos's etc to do so!

Thank you for your feedback and support! No worries about the enlgish.

Feel free to join us in discussion in our IRC chat room: http://webchat.freenode.net/?channels=#digibytecoin

We are officially naming our next update:DigiByte v 2.0.0-DigiShield

Each successive major release of DigiByte will be accompanied with a "Digi" name.

The DigiShield update will serve two main purposes: To shield from multi-pools and an over inflation of new coins (0.5% weekly reward reduction). We are testing a few more configurations before we release the update. We are pushing back the block where the changes will kick in to next Friday.

After testing multiple configurations (30+) of our own code, the Kimoto Gravity Well and Earthcoins one minute block configuration we have learned a few important lessons over the last week.

First, it is essential that a re-target occur with every block. There is just no other way to do it. Second, it is not possible to allow for a faster re-target than 60 seconds as multiple errors occur and the client crashes while mining (with 60 second block spacing). Third, even the Kimoto Gravity Well allows for a fair amount of "insta" mining following a major hash increase. So does the Earthcoin approach. Both are not very effective and will still allow multi-pools a few minutes of mining and are not all they are hyped up to be. Earthcoin still gets hit by multi-pools for 11-12 minutes at a time. Same will happen to DigiByte even with a KMG implementation.

The truth is both those approaches limit the amount the difficulty is allowed to change each time. This becomes an even bigger issue with a sudden hash decrease. While simulating a sudden 20-40 fold hash decrease the Gravity well can become "stuck" for a few hours before evening out again. Since it takes several blocks for the hash to come back down it really adds up when it takes 20-30 minutes to discover each block for awhile. Same with the Earthcoin approach, this is why they get "stuck" for 20-40 minutes following an 11 minute hash increase from Hash cow.

We know a 20-40 fold hash increase is not usual, but it could happen. More than likely we will only see a 5-10 fold increase. Non the less, we want to make sure we can handle sudden extremes very quickly.

With our own custom implementation we have tested many different variations on how far the difficulty is allowed to jump each block. The more we allow the difficulty to jump, the faster it adapts. Pretty much every scrypt based coin out there only allows a jump by a factor of 4 within a block retarget. This is most likely because that is what Litecoin implemented. This makes sense with a multi day difficulty re-target (Litecoin 3.5 days), as anything more could kill a coin as a dramatic hash increase could push the difficulty so high it took weeks for the next re-target to occur for a new or smaller coin with limited hash.

Litecoin limit code:

We feel pushing this up from a factor of 4 to a factor of 200-2000 is the way to go. This allows for very dramatic adjustments with every block which means very quick adjustments to hash movements. This approach has far out performed the Gravity Well or Earthcoin code. There are a few other settings that play into the difficulty adjustment process, but we have seen the most success moving this # upwards in conjunction with a few other settings.

We have made instant hash simulations going form 200-8000 kh and then vice versa. We have also tested 200 - 4000, 200 -2000 and a few others. As expected the 200 - 8000 kh swings (40 x) are the most dramatic and cause most configurations to be "stuck" for an hour or more (KMG included).

KMG works fine for smaller adjustments every block, but offers no additional benefit with major hash swings. It basically "breaks" with very large hash swings.

Our delay right now is deciding exactly how much we should allow the difficulty to adjust with each block. The performance from our tests indicates the equivalent of 200x allows for the fastest adjustments up and down within a reasonable amount of time.

Is there something we are over looking here? With a much higher (actual) hash load will this adjustment act differently? What are the dangers of allowing very large diff swings like this?

Also, with a higher difficulty # like the 10-20 range we currently see, will we see any other phenomena that we can't test in the low hash test-net environment? Are we on the right path?

+1
Funny, we decided on this name yesterday. It appears all the great minds in the DigiByte community think alike! Glad to see it was arrived at independently of the dev team!

Please feel free to come to IRC to discuss the difficulty adjustment: http://webchat.freenode.net/?channels=#digibytecoin

We are officially naming this update:DigiByte v 2.0.0-DigiShield

Each successive major release of DigiByte will be accompanied with a "Digi" name.

The DigiShield update will serve two main purposes: To shield from multi-pools and an over inflation of new coins (0.5% weekly reward reduction). We are testing a few more configurations before we release the update. We are pushing back the block where the changes will kick in to next Friday.

After testing multiple configurations (30+) of our own code, the Kimoto Gravity Well and Earthcoins one minute block configuration we have learned a few important lessons over the last week.

First, it is essential that a re-target occur with every block. There is just no other way to do it. Second, it is not possible to allow for a faster re-target than 60 seconds as multiple errors occur and the client crashes while mining (with 60 second block spacing). Third, even the Kimoto Gravity Well allows for a fair amount of "insta" mining following a major hash increase. So does the Earthcoin approach. Both are not very effective and will still allow multi-pools a few minutes of mining and are not all they are hyped up to be. Earthcoin still gets hit by multi-pools for 11-12 minutes at a time. Same will happen to DigiByte even with a KMG implementation.

The truth is both those approaches limit the amount the difficulty is allowed to change each time. This becomes an even bigger issue with a sudden hash decrease. While simulating a sudden 20-40 fold hash decrease the Gravity well can become "stuck" for a few hours before evening out again. Since it takes several blocks for the hash to come back down it really adds up when it takes 20-30 minutes to discover each block for awhile. Same with the Earthcoin approach, this is why they get "stuck" for 20-40 minutes following an 11 minute hash increase from Hash cow.

We know a 20-40 fold hash increase is not usual, but it could happen. More than likely we will only see a 5-10 fold increase. Non the less, we want to make sure we can handle sudden extremes very quickly.

With our own custom implementation we have tested many different variations on how far the difficulty is allowed to jump each block. The more we allow the difficulty to jump, the faster it adapts. Pretty much every scrypt based coin out there only allows a jump by a factor of 4 within a block retarget. This is most likely because that is what Litecoin implemented. This makes sense with a multi day difficulty re-target (Litecoin 3.5 days), as anything more could kill a coin as a dramatic hash increase could push the difficulty so high it took weeks for the next re-target to occur for a new or smaller coin with limited hash.

Litecoin limit code:

We feel pushing this up from a factor of 4 to a factor of 200-2000 is the way to go. This allows for very dramatic adjustments with every block which means very quick adjustments to hash movements. This approach has far out performed the Gravity Well or Earthcoin code. There are a few other settings that play into the difficulty adjustment process, but we have seen the most success moving this # upwards in conjunction with a few other settings.

We have made instant hash simulations going form 200-8000 kh and then vice versa. We have also tested 200 - 4000, 200 -2000 and a few others. As expected the 200 - 8000 kh swings (40 x) are the most dramatic and cause most configurations to be "stuck" for an hour or more (KMG included).

KMG works fine for smaller adjustments every block, but offers no additional benefit with major hash swings. It basically "breaks" with very large hash swings.

Our delay right now is deciding exactly how much we should allow the difficulty to adjust with each block. The performance from our tests indicates the equivalent of 200x allows for the fastest adjustments up and down within a reasonable amount of time.

Is there something we are over looking here? With a much higher (actual) hash load will this adjustment act differently? What are the dangers of allowing very large diff swings like this?

Also, with a higher difficulty # like the 10-20 range we currently see, will we see any other phenomena that we can't test in the low hash test-net environment? Are we on the right path? What are your thoughts?

Yes, that about sums it up. And we have destroyed several configurations with it, including the gravity well. What we have came up with will be much better because of the extreme testing.

We apologize, we are getting closer.

We have ran through some very in depth tests. We have proved the KMG is not all it is cracked up to be. We have been up working on it for 14 hours now today so it will be tomorrow morning as it is approaching 2 AM here. We would much rather have a delayed update than a failed one.

We wanted to give another update to let you know that we are testing and comparing the Kimoto Gravity Well implementation against our own custom re-target code. We wanted to make sure we release the best possible solution for the current multi-pool problem. As no one has been able to give us a technical description of KMG, nor can we find much reading material on it we are testing exactly how it performs under load with DigiByte code.

We have recompiled and tested about thirty different code configurations over the past few days. We are timing re-targets and averaging them out over several hours. We are also simulating up to a 40 fold instant hash increase or decrease. We want to find the best possible solution that will serve DigiByte many years into the future.

We apologize for the delays, but we would rather do things right the first time then have to re-fork and re-update a few weeks or months later.

We will be trickling them out one at a time. We will release git source first, then Windows & Linux and Mac will probably be last with Android in the middle.

We will make sure to test them all before hand. We will announce as each is released.

Update on the Update:

The great news is we have successfully implemented and tested both the reward reduction code and the difficulty re-adjustment code. They are working as expected. We have also made some visual enhancements to the Wallet.

We, however would like to test the difficulty code out with some more extreme difficulty swing tests before releasing it. We want to make sure it can handle anything a multipool can throw at it so we only have to go through this once.

We are just about an hour from when we had initially schedule the release, so we are going to push it back 8-12 hours for proper testing time. (It takes a few hours to run a testing cycle on the testnet block chain).

Once released everyone will have until next Wednesday to update. Both the reward reduction and block difficulty adjustment will kick in about next Wednesday at block 64600. This gives five days for everyone to download update, most importantly mining pools.

We would like the difficulty code to kick in right away but this is not feasible as several forks could emerge and cause a lot of chaos. If everyone updates by then the transition will go smoothly at block 64600 and DigiByte will proceed on its journey to the moon!

The 0.5% reduction is used in place of the halving every 2 years.

+1 Very cool, we have not seen this before!

Very interesting idea. What about the robot next to the DigiByte logo in the wallet?

Very good. We will look into this for sure! Thank you for posting that!

For sure, post away! We are open to all ideas and suggestions. We can't think everything up. You guys in the community are what gives DigiByte the future it has!   

See your point, how could they lookbetter?

How do you propose we do this? Bman3 had some awesome 3d graphics?