From:
https://forum.decred.org/threads/dd-22-v1-0-0-04-25-17.5312/ 
This development dispatch covers work completed since the Decred v0.8.0 release on February 13th, 2017. Since then, developers have merged over 250 pull requests into 11 repositories.
Here are direct links to the Paymetheus (Windows) GUI wallet installers:
Paymetheus v1.0.0 64-bit
https://github.com/decred/decred-binaries/releases/download/v1.0.0/decred_1.0.0-release_x64.msiPaymetheus v1.0.0 32-bit
https://github.com/decred/decred-binaries/releases/download/v1.0.0/decred_1.0.0-release_x86.msidecrediton (OSX, Linux) GUI wallet installers:
decrediton v1.0.0 Linux 64-bit
https://github.com/decred/decred-binaries/releases/download/v1.0.0/decrediton-1.0.0.tar.gzdecrediton v1.0.0 OS X 64-bit
https://github.com/decred/decred-binaries/releases/download/v1.0.0/decrediton-1.0.0.dmgdcrinstall cross-platform text-based CLI installers:
dcrinstall v1.0.0 All platforms
https://github.com/decred/decred-release/releases/tag/v1.0.0all the various binaries except for dcrinstall:
all v1.0.0 binaries
https://github.com/decred/decred-binaries/releases/tag/v1.0.0NOTE: All Windows binaries only support Windows 7 and newer.
In the last 2.5 months since the release of 0.8.0, Decred has seen another substantial increase in its exchange rate, which went from DCR/BTC of 0.0025 to an all-time-high of 0.0218 and settled above 0.01, and a corresponding surge of new users, based on GitHub downloads of 0.8.2 binaries increasing by over 100% relative to 0.7.0. While this improvement in the exchange rate and community engagement is great news, what we're most excited about is hard fork voting being put into production on mainnet with this 1.0.0 release. The introduction of hard fork voting on mainnet means that the stakeholders will be able to vote on major decisions, referred to as agendas, that affect the future of Decred.
Hard Fork Voting on mainnet
The 1.0.0 release of Decred includes the first 2 such agendas that will be voted upon:
whether or not to use a new ticket price algorithm
whether or not to begin development work to support the Lightning Network (“LN” for short)
The ticket price algorithm change will be a substantial improvement over the existing one, based on the simulations posted on GitHub. If stakeholders vote yes and signal they want LN support, the developers can begin working to accomplish that with confidence the code changes will be voted in and activated in the future. It is expected that voting on and activation of these agendas will take 3-4 months:
roughly 1 month for miners and stakeholders to update to version 1.0.0, which signals support for the new block version, vote version and then stake version
up to 3 weeks to wait until vote tallying begins
4 weeks for votes to be tallied, at the end of which, any agenda receiving over 75% 'yes' votes is locked-in for activation, any agenda receiving over 75% 'no' votes is marked as failed, and all other agendas roll over to be voted on in the next 4 week voting interval
4 weeks for locked-in agendas to become active and have their changes enforced on mainnet
It is worth noting that Decred not only allows its stakeholders to vote on these critical changes, but these changes are activated via a pre-coded mechanism in the software. Decred's consensus daemon, dcrd, comes with these conditional consensus changes pre-coded and ready to activate once stakeholders vote them in.
This release is a notable milestone since it is the first step in disintermediating politics within Decred. We aim to “share the wheel” with our stakeholders to both eliminate conflicts of interest present with having an elected or appointed representative, such as myself, and because we believe we can make better decisions for Decred as a group than individually. Some modern governance organizations take a similar approach by episodically holding referendums on important issues. Consensus changes can have wide ranging consequences for Decred, so it is only fair to solicit the opinion of our stakeholders as part of this process.
It is worth noting that the LN support agenda is not a consensus change, but we have still added it as an agenda. If the results indicate strong stakeholder support for supporting LN, that work can begin with minimal risk before the vote has completed. In the future, hard fork voting will almost exclusively relate to consensus changes, to keep on-chain data to a minimum, but we wanted to assess stakeholder sentiment for this before work begins. Voting on decisions that do not affect consensus code would be better handled somewhere off-chain, which we will be working towards after this release.
GUI Wallet Voting and Staking
Both Paymetheus and decrediton have added support for setting voting preferences at a user's stakepool. Setting your voting preferences with your stakepool requires that the stakepool support the new v2 stakepool API, so it may take a few weeks to get this supported across all stakepools. Setting voting preferences is an action that a user will typically perform only once during a giving voting cycle, so this only needs to be done once every several months, as opposed to manually for every vote cast.
decrediton now supports several staking features previously only available in Paymetheus, along with automatic ticket buying, which Paymetheus does not yet support. Users can now connect to their stakepool using the API, manually purchase tickets, and also automatically purchase tickets. It is recommended that users take caution when setting up automatic ticket buying since its increase in convenience is accompanied by heightened security risks and requires episodic human supervision.
Wallet Infrastructure
A couple major changes have been made to dcrwallet's infrastructure that should be mostly transparent to users. As part of our initial release, a concept of "address pools" was added to dcrwallet that solved some short-term issues, but this has led to several problems once it was in production. Address pools have been removed and a look-ahead buffer for addresses has been added in its place. This properly implemented look-ahead buffer has the benefit of allowing users to use multiple wallets with the same seed without event, unless wallets that share a seed are concurrently attempting to create transactions.
The second major change addresses wallet database versioning and error handling: the various components of the database are now coherently versioned and error handling has been simplified. With the previous database versioning scheme, there was potential for database corruption as a result of version mishandling, but this is now properly versioned and unified, along with the error handling.
Required gominer Update
As part of the fix for the recent proof-of-work mining pool "outage", users of gominer must upgrade to the latest version, unless they are mining in solo mode. This is required due to the fixes made to ensure that the stake version is set properly by mining pool software.
Re-architected dctstakepool
Stakepools have been running on mainnet for over a year now, and as part of supporting hard fork voting, we have re-architected the stakepool software, dcrstakepool. After receiving feedback from stakepool operators, we decided that changing the architecture made sense. The old architecture had a stakepool update votebits on every individual ticket on every voting wallet when users of the pool updated their voting preferences. Prior to the start of hard fork voting, users would not regularly change their votebits, but now that this action will occur more frequently, stakepools need to efficiently handle these user changes.
To compensate for the increase in frequency of users changing their voting preferences, a new daemon, stakepoold, has been added to the configuration that mediates the setting of ticket votebits according to each user's preferences. Instead of pushing all the votebit setting and ticket management to voting wallets, stakepoold watches for notifications for votes and new pool tickets, then it tells the wallet how to create each vote according to its owner's voting preferences. This avoids all the churn and load associated with setting individual ticket votebits across several voting wallets, and sets the votebits according to user preferences "just in time".
We have been testing the current dcrstakepool code on testnet for a couple weeks now, and it has worked without serious event thus far. Prior to this release, we were able to perform a preliminary deslugging of the code, but we have not completed this process and performance tested relative to the old architecture. Voting is a latency-sensitive operation, so in order for mainnet stakepools to upgrade with confidence, we must verify the latency of this configuration is sufficiently low. There will likely be one or more patch releases of dcrstakepool as part of upgrading existing mainnet stakepools to the new version. In the meantime, stakepool operators can start to prepare for the upgrade using this release.
Next Steps
Now that we have covered what this release accomplishes, it is instructive to consider what kinds of decisions are not a good fit for the on-chain voting process. Decred, as an organization, must make many types of different decisions in order to continue building its infrastructure, expanding its user base, and increasing its utility to its users. If we voted on every single minor decision, not only would it take a long time to get anything done, it would lead to a lot of on-chain bloat, along with several other negative side effects. With these considerations in mind, we will begin work on a new tool that allows users to construct an ongoing record of off-chain data that is anchored into the Decred chain episodically, creating a time-ordered set of records. In the context of Decred governance, we will build a proposal system using this tool, with the following properties:
the proposal records will be publicly available
users can submit proposals via the system
submissions will have an associated fee to prevent spam, which can be refunded under certain conditions
the records are episodically anchored into the Decred chain to create a time-ordering
Once this tool has been developed, we can begin the process of disintermediating the other smaller decisions that occur within Decred. For example, future consensus changes will be submitted via the proposal system, and after assessing stakeholder sentiment, can be put to an on-chain vote. The goal is to have all decisions that relate to funding and voting route through this proposal infrastructure. A proposal system as described should be able to handle most of the smaller decisions that Decred needs to make on an ongoing basis.
The medium term goal I have for Decred is to replace myself with a collection of minimally-complex non-Turing complete smart contracts. Once that process is complete, Decred will have a robust governance system with minimal conflicts of interest, which can control the development subsidy and direct the project as stakeholders see fit.
Public keys
The file cmd/dcrinstall/pubkey.go contains the decred public key which is used to check the signed manifest in the release. You can compare the contents of this file to what you get from a keyserver to confirm that dcrinstaller is using the proper key.
Contributors
And a big thank you to everyone who contributed to this release: @davecgh, @moo1337, @jrick, @ay-p, @jolan, @jcv, @dhill, @raedah, @javed-khan, @karamble, @linnutee, sander, @gratefulcheddar, @Shadowlance, jholdstock, boblin, Baggins800, Kmaschta, @chappjc, @peterzen, captain-redbeard, @girino
