Welcome to Ember’s Weekly Update #3, covering 9/17/18 to 9/23/18! This week has less progress than usual for reasons I’ll describe after I cover Ember’s progress.

First, we changed how the difficulty algorithm is used. The difficulty used to recalculate every 10 minutes, and now it recalculates based on the block count. We also added a dynamic period length, which will increase as time goes on until it finalizes at retargeting daily.
- For the first month: Every block.
- For the next 2 months (until the end of month 3): Every hour.
- For the next 3 months (until the end of month 6): Every six hours.
- For the next 6 months (until the end of month 12): Every 12 hours.
- From then on: Daily.
This is for a few reasons. When Ember launches, we’ll have a small amount of miners, meaning that the hash rate will fluctuate more. Therefore, retargeting every block is better. However, we believe Ember has the potential to be a large coin. In fact, we believe Ember could be in the top ten someday, and large coins do better with a longer retargeting period. 1 day is optimal in our opinion, unlike the 2 weeks BTC uses, and after an year, the hash rate should be large enough for that. The steps up is just to smooth out the process.

We also upgraded how the difficulty algorithm calculates difficulty, and applied a direct scaling algorithm (if the blocks took 12 minutes, divide the difficulty by 6 and multiply it by 5). Next, we made the algorithm a bit less direct. The difficulty change is capped at 10% of the valid hashes for a block. This is to stop radical scaling upwards/downwards. It was just 10% of the amount it could scale in either way, but that was problematic.

Imagine the difficulty is 0 to 100. If it’s 0, everything will be valid. If it’s 100, nothing will be.The block hash must be higher than the difficulty, so the difficulty will be on the high end. Let’s say the difficulty is 80. If we scaled on the amount it could travel, it could jump 8 down, but only 2 up. This led to the difficulty increasing slowly up, and up, until it went too far, but then jumping back down the max, restarting the process. Now it only can only scale 2 each way.

Next, we upgraded the address from Base58 to Base32. We’ll later improve addresses further to implement Bech32’s BCH codes, which will provide error correction abilities. This offered a massive speedup, easier to read addresses, safety via error correction, yet only increased the address length by 10 characters (<20%, when most people will copy and paste them).

Next, the explanation for why Ember didn’t have as much progress as usual. We have been working on FireUI.

What’s FireUI? FireUI is a GUI library which Ember will use. All the options available were problematic to the point we didn’t want to use them, in order to provide the best user experience possible. Because of that, we started writing a GUI based around SDL; a platform independent graphics (not GUI) library.

Due to the work involved with this task, and the fact we were effectively creating a library, just one built in to Ember, we decided to create a proper library so that other people can use and contribute to it. Over the past week, FireUI has made a lot of progress. We’ve created a window, drawn onto the screen, implemented a grid layout with “Sections” and “Elements”, achieved a consistent FPS…

As for why we’re building this GUI library now when we still don’t have a fully functioning cryptocurrency, it’s to speed up testing. We need some UI to test the usage of the various pieces of the cryptocurrency. We’ve been using CLIs, but they are slow and frustrating. We could keep using CLIs, being slowed by the time it takes to develop/use them, and be frustrated while we do it, or we could work on the GUI now, instead of later, when we would do the exact same work. Since we had to do it at some point, we decided now was the best time to.

That concludes this week’s updates! As we have said every time, we look forward to Ember’s future, and we will update you next week, on Sunday, with our progress.

EDIT: After a week of developing FireUI, and after going over the performance with the samples we’ve written, we’ve decided it’s simply not worth it. We were hoping we could obtain the best GUI possible for Ember and provide an amazing user experience. That said, after seeing how long we’ve spent on the GUI library so far, recognizing a proper GUI library will need a month or two more before it’s usable, and the fact we started all this to build a cryptocurrency, not a GUI library, we’ve decided to switch to WebView.

It’s an integrated web browser that will allow the GUI to be written in HTML/CSS/JS, will work on all the major platforms, and doesn’t have the bloat of Chromium. The only regrets the team has are the time wasted and the fact this Weekly Update was published just a few hours before we made this decision.