This is a maintenance release. Updating is advised, but not required.
- Improved wallet loading speed.
- New checkpoints and updated seeds.
- Versioning code improvements.
- Minor in-wallet improvements.
- Removal of testnet and regnet code.
- Removal of Tor/Onion routing network support.
SHA256sums:
2c91cd51de3e580e60c845233ce2d530c7d6daeb0d6e9c5839906ab8f00b12ba auroracoin_2017.02.1.0-0ubuntu1_amd64.deb
778e853c2b7e52cbaf15d1271bb93b1c6cd077274772d9984aedb40676754d7b
auroracoin-2017.02.1.0.tar.bz2
7b6ce2cedc8011019617a96ad6ec5ad611f6d758e622408703e0c80ecce5b652
auroracoin-qt-20170210.exe
Downloads
This is a maintenance release. Updating is advised, but not required.
This release includes:
- New checkpoints (post-multialgo)
- Upgrade to BerkeleyDB 5.3
- Restore of the original minimum difficulties for all algorithms
- Initial code cleanup in main.cpp
SHA256sums of the files:
76ed5e634bddf61b6fd9598ccc50de703a7144f70aa597c3871124eaca11e9a2 auroracoin_2016.08.1.0-0ubuntu1_i386.deb
6535012cb66538e1b3c9859732d238f624e290d8827aabd462d70854d45d3cb1 auroracoin-2016.08.1.0.exe.zip
eb002da1525cda379334c0c92ca9cf59fd8b8ffc37c3dc18a4f04501f92847a4 auroracoin-2016.08.1.0.exe
dc239ed4a6d217d81e725f9eb7c35e6d21311e3f9c263f8f9b5d659be0698312 auroracoin-2016.08.1.0.tar.bz2
Downloads
This update fixes 2016.04.1.0, where some of the provided builds could not import the paper wallets.
MacOSX users can keep using 2016.04.1.0, as that build isn't affected.
SHA256sums:
8da1ab7777ee563e96cae831b3bb9e149bdd9600434aa695987771e6365df07a auroracoin-2016.05.1.0.tar.bz2
4e7106b6d18b9888d16af71144ecddec10540a28fa2877324dc1b257937964c6 auroracoin-qt-2016.05.1.0.exe
c51a3cf736339f900e374f4917762c53e417b1a866ae5c7e24f1189ef275b6a3 auroracoin_2016.05.1.0-0ubuntu1_i386.deb
Downloads
This is an optional update for users looking to import existing paper wallet keys.
This release fixes an issue with trying to import existing private keys with the KEY_SECRET value of 151. The patch adds existing private key support and does not require a fork. Existing users do not need to update, unless they are trying to import a private key from wallet version prior to the April 2016.03.01.0 release.
Please note- this development release reads version 2016.04.01.0, but the pre-compiled wallet version info will still read 2016.03.01.0.
Downloads
THIS VERSION CREATES A HARDFORK AT BLOCK 225000
Change in codebase– This release moves us from the version 0.8.7.5 Litecoin codebase to the 4.0.3 DigiByte codebase. Early discussions about moving to a multi-algo codebase left us with the decision of Myriadcoin or DigiByte as our foundational code. After some great discussions with Jared Tate, founder of DigiByte, we decided to use their codebase. Additionally, DigiByte released their version 4 DigiSpeed code during early development, and we immediately made the change over from version 3. The codebase is solid, secure, and well tested. It will make a great foundation for Auroracoin going forward.
61 second block time– When discussing how we were going to structure block times in a multi-algo implementation, we decided to do something a little different. With the addition of the multi-algo block time change, we have decided to make the timespan between blocks 61 seconds. The number 61 is in reference to the year that the centralized banks were founded in Iceland. It is a constant reminder of why AUR is so important for the Icelandic people.
Multi-algo specifics– Our wallet implementation builds on the the Digibyte codebase. As such, we decided to use the same algorithms that have proven successful for DGB- SHA256, Qubit, Groestl, Skein, and Scrypt. This allows not only for existing SHA256 and Scrypt mining ASICs to mine AUR, but also GPUs and CPUs with energy efficient algorithms that help decentralize our mining efforts. Each algorithm still paces blocks at 5 minute 5 second intervals. However, with all 5 algorithms mining collectively, the block spacing will be 61 seconds. This change should eliminate blockchain stalls we have seen in the past, because if one algorithm takes longer to mine the next block, another algorithm can step in and keep the chain moving. Not only does this contribute to faster block confirmation times, from 30 minutes to 6 minutes 6 seconds, but it also adds the needed blockchain stability and security that we’re striving to achieve. Additionally, it mitigates multipool activity on the chain, as no single algorithm can control lower difficulty mining.
Block rewards– Multi-algo dramatically changes mining dynamics. While there is a 5 time increase in blocks per day, we didn’t want to see a dramatic increase in coins created per day. Previously, the block reward was 12.5AUR per 5 minutes. To stay true to the coins created per day, we reduced the block reward of the multi-algo blocks to 2.5AUR every 61 seconds. This equates to 12.5AUR every 5 minutes and 5 seconds. This is of course a 1.66% decrease in block rewards due to the 5 second increase in time. However, with mining luck and the increase in mining longevity, we think that the 1.66% decrease will be negligible over time.
Halving schedule– Due to the 5 time increase in blocks, we needed to adjust the halving periods to compensate. The new halving block period is every 2.1million blocks, a 5 time increase from the previous 420k blocks.
Consecutive algorithm block limit– In testing, we identified a few instances where miners could essentially manipulate lower-difficulty algorithms with no active miners to mine 2-3 times the number of blocks that they would normally be able to mine. It’s not a bug in the code, but rather an exploitable mechanic that could be abused by smart miners. In order to prevent this exploit, we have implemented a consecutive algorithm block limit. This system essentially counts the number of blocks that a single algorithm has mined. If the algorithm has mined the previous 5 blocks, it cannot submit a block to the chain before another algorithm has submitted a block. This is an effective mechanic that not only makes mining fair for all, but also deters the abusive profitability scripts used by multipools and opportunity miners.
New versioning standard– Going forward, client versions will be denoted in a date/release format of YEAR.MONTH.RELEASE.PATCH. For instance, this release will be 2016.03.01.0. This helps facilitate version discussion and identification in a logical and streamlined approach.