[DCR] Decred | BLAKE256 | PoW/PoS | v1.1.0 (2017-09-23) - Decentralized Blockchain Governance

Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred solves blockchain governance and rewards you for voting.
What we're building will empower your ideas, give you control over decisions, at lightning fast speed, while protecting your privacy.


Decred allows users to seamlessly transition from one set of consensus rules to another. This is a complex problem, as demonstrated by the difficulties experienced in Bitcoin governance. Decred uses an innovative hybrid proof-of-work (PoW)/proof-of-stake (PoS) system similar to proof-of-activity (PoA) to solve this problem and gives users of the currency decision-making power about the set of consensus rules to activate.

This hybridized consensus system is used to strike a balance between miners and users to create a more robust currency. Typically, the miners who operate the infrastructure wield considerable influence while the users have relatively little sway. Decred allows users to participate in the project directly without the need for expensive mining hardware.

Decred fosters a multi-stakeholder development ecosystem that welcomes and empowers participants who want to improve on existing features or build new tools. Anyone can submit feature proposals, and developers are paid for work to fulfill requirements in full view of the community. Funding for this work comes directly from the Decred blockchain.

The main Decred development group started as the Bitcoin developers who develop btcsuite, a widely respected Bitcoin implementation in Go that has been used by several high-profile projects including, but not limited to, BitGo, Factom, Ethereum, and the Lightning Network. Several of Decred's developers have also been contributors to the core of OpenBSD, among many other projects. Anyone is free to join development as an individual, a group, or a company - as many have already!

Community and Principles
Decred is constructing a layered governance organization that extends beyond the miners and users to bring forward and represent insider and outsider voices in the community. Decentralization is a process, and a decentralized ledger is only the first step in that process.

The project is bound by the Decred Constitution, so users can know what to expect: a finite number of coins, decentralized governance and a place to share their views. Decred's community plays an important role in making decisions, both informally via the Decred infrastructure and formally via the blockchain.



GUI Wallets (bundled with dcrd/dcrwallet):

Core software:

  • Command Line Suite - cross-platform, automatic installer/updater for the command-line applications
  • Webwallet - no downloads required

3rd Party Wallets:

  • Exodus - friendly, all-in-one application, to secure, manage and exchange blockchain assets.


  • 2017 Milestones

    • Public Proposal System
      • Introduction of the first censorship-resistant and blockchain-anchored public proposal system, which empowers users to submit their own projects to Decred for self-funding from the project's block subsidy
    • Stakeholder-directed DAO
      • Convert Decred into a stakeholder-directed distributed autonomous organization (DAO), whereby users are given further control of development funds through voting
    • Lightning Network support
      • The two projects' respective lead developers work closely together - lnd and Decred are based on btcsuite, which was also developed by Decred's own developers
    • Enhanced User Privacy
      • Highly anticipated project within Decred likely to attract widespread attention
  • Completed

    • Novel hybridized proof-of-work/proof-of-stake (PoW/PoS) consensus system
    • Cold staking and decentralized stake pooling
    • Internal voting system for the addition of new features and hard or soft fork selection
    • Immutable transaction hashes ("transaction IDs") by separating transaction signatures from the rest of the transaction data
    • Elliptic curve cryptography over secp256k1 with optional Curve25519 support
    • Schnorr signatures with threshold n-of-n support
    • PoW mining using BLAKE256 hash algorithm
    • Hierarchical deterministic (HD) wallets
    • Transaction expiration
    • Patches for intrinsic Bitcoin bugs


Who works on Decred?

Decred operates through a resilient contractor model that allows for new individuals, groups, and companies to contribute to the project. At present, Decred consists of a large number of contributing members who work on the project:

  • 14+ developers who actively contribute new code, maintain current code, and implement roadmap features in Decred's free and open-source software and repositories.
  • 19+ marketing/community helpers who develop a number of clearly defined areas for Decred: (1) advertising, (2) media, (3) networking, (4) platform management, and (5) special projects.
  • 8+ designers work alongside the developers and marketing contractors to develop solutions in disciplines of (1) UX/UI, (2) identity, and (3) visual communications.



  Mining Software
  • gominer - CUDA/OpenCL miner for AMD/NVIDIA GPUs
  • ccminer - 3rd party CUDA miner for NVIDIA GPUs
  • sgminer - 3rd party OpenCL miner for AMD GPUs
⠀⠀⠀ Exchanges
  Proof-of-Work (PoW) Pools
⠀⠀⠀ Proof-of-Stake (PoS) Pools

Technical Brief | Documentation | Voting Dashboard

Latest Release: v1.1.0 (2017-09-23)
Release Notes

Posted: 3/28/2016 11:13:43 AM Edited: 9/25/2017 11:36:08 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.0.9 released, release notes below
This development dispatch covers work completed since the Decred v0.0.8 release from March 18th, 2016. Since then, developers have merged 21 pull requests of code into 3 software repositories. During this period, a total of 25 commits occurred in these repositories and represent modifications to the effect of 8,622 lines of code added to and 13,221 lines removed from the codebase.

A new request for proposal (RFP) has been opened to establish and operate additional stake pools in a number of geolocations. Several parties have stepped forward, and the project is working with them to set up the new infrastructure. Design deliverables for RFP-1 are nearing completion, the first component of RFP-4 is complete and will be integrated into a documentation system in the future, and a number of milestones are being completed and put into Decred repositories for RFP-5. Work continues on RFP-1 through 6. Finally, Paymetheus, the Windows wallet GUI for Decred has been made available as a testnet pre-release prior to the completion of RFP-1's improvements.

Binaries: https://github.com/decred/decred-release/releases/tag/v0.0.9

  • Added new IsUnspendable function required for the latest dcrwallet sync that takes a public key script and returns whether it is spendable (96-5fcef8a)
  • Removed an extraneous check (98-7a15800)
  • Updated versioning (97-5fcef8a, 99-0ed0e81)
  • Corrected and simplified shutdown logic for interrupts (127-2b79aad)
  • Disallowed naming accounts with an empty name. Any accounts in the database that are already named the empty string are left untouched and should be renamed to something meaningful by the user (127-9fe02c4)
  • Made wallet manage wallet database namespaces from the wallet package (127-fcccae3)
  • Prevented a race when setting a new relay fee through the legacy RPC server (127-d09c2a8, 127-d09c2a8, 127-5d6392b)
  • Refactored wallet transaction creation code (127-f084802)
  • Removed legacy JSON-RPC notifications (127-6cf22b7)
  • Updated logging for wallet locks and unlocks (127-6e6cb30, 127-71649ab)
  • Updated startup configuration (127-cee0411)
  • Synced dcrwallet to the latest btcwallet branch master branch. Includes general all around cleanups, pulls in new packages for improved transaction creation and fee estimation, which is now used when creating basic p2pkh transactions. Fee estimation constants and test vectors have also been updated for Decred's transaction sizes (127-2133b7b)
  • Added a new wtxmgr API for resumable, incremental input selection that is performed under a single database transaction, and hooks up the API for transaction creation in the wallet package (130-b0aff95)
  • Fixed updating the UTXO set for imported addresses to always update spending data even if the transaction already exists (133-a488b38)
  • Refactored address pool code to scale to more accounts than the default account, updated address pools to be generalized so that in the future they can be multi-account, and greatly simplified logic for the address pool. Accounts are automatically resynced when the wallet is restored from seed (134-4b64adf)
  • Removed voting pool package as it is currently unused in Decred (135-d98dc43)
  • Ensured resync has been completed before launching notification handling so that wallet would not drop or mishandle notifications that came in synchronously when wallet resynced (136-6bf720c)
  • Fixed proportion missed calculation in the getstakeinfo RPC request (138-1a89f7e)
  • Increased test coverage by fixing waddrmgr tests (139-b110e4e)
  • Modified logic for password prompting (142-5141dfa)
  • Added safety checks for address pool access to ensure that the address pool exists and has been initialized before calls to its functions or internals (143-125bbdd)
  • Fixed various issues identified by the static checkers (144-0c80297)
  • Updated licensing (127-5140086), RPC naming (127-82e7437), documentation (127-397bead), and versioning (126-0d61bd9, 127-b1500ba, 150-4387fa3)
  • Added RFP0006: Setup and Operate 10 Stake Pools (15-7bf1adb, 16-ac8847e)

Posted: 4/2/2016 8:52:56 AM Edited: 4/2/2016 8:55:02 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.1.1 released, release notes below

This development dispatch covers work completed since the Decred v0.1.0 release from April 18th, 2016. Since then, developers have merged 18 pull requests of code into 3 software repositories. During this period, a total of 18 commits occurred in these repositories and represent modifications to the effect of 848 lines of code added to and 275 lines removed from the codebase.

A series of RFP milestones were achieved and paid for from the development subsidy. Milestones paid for include (See: Status and Expenditures):

  • RFP-3: Port has been completed (limited milestones) (6ae7950)
  • RFP-6: Pool has been successfully tested for 1 week on testnet and configuration verified (x4) (e5bcf90, f9ea04d, e94c540, fc58177)

Binaries: https://github.com/decred/decred-release/releases/tag/v0.1.1

  • Added a check to disallow by default transactions to be broadcast if the fee per kilobyte is 100x above the minimum (0.01 DCR). This check does not affect other incoming transactions to the node, it only checks transactions going out of the node (124-b7e88f4)
  • Added a new RPC command called ticketfeeinfo to provide statistical information about ticket fees per kilobyte for the mempool, recent blocks, and recent difficulty windows (132-41abd20)
  • Updated fee calculation (125-a5ca12f), error handling (127-82a0e17), documentation (128-fd40243), and versioning (136-4f8ad73)

  • Fixed the build when using newer versions of the gRPC packages (189-3f411f0)
  • Isolated the address pool to prevent excessive address creation (192-4e689d6)
  • Fixed an issue where the purchaseticket RPC command would fail if the ticket address or pool address was undeclared, not allowing the user to set the ticket expiry if either was absent (198-0740964)
  • Added ability to change the ticket autopurchase frequency and changed the frequency to a default of 1 (can be changed with the command-line argument --ticketbuyfreq=) (201-823bddb)
  • Fixed an issue that prevented Paymetheus from starting properly (203-b28ae9a)
  • Updated dust calculation (193-df0af6e), fee calculation (194-5d77ddb), documentation (195-2a1e04c, 208-0bcc487), index scan length (196-38cdae0), user prompts (202-8ed9a8c), and versioning (209-c5e47fb)

  • Updated documentation (13-c69fe51)

Posted: 4/30/2016 3:41:07 AM Edited: 4/30/2016 5:58:47 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.1.0 cgminer and ccminer released, release notes below



This is a binary release of cgminer and ccminer for decred. Binaries
for 64bit Linux and Windows are provided.

The attached manifest file can be used to confirm the sha of the

See README.md for more info on verifying the files.

Changes include:

Description Pull Request
blake kernel optimisation for nvidia cards decred/cgminer#24
Fix broken intensity. decred/cgminer#25
Fixed high CPU usage and time-too-new bug. decred/cgminer#27
.gitignore the rest of the generated files. decred/cgminer#28
Use decred specific version number. decred/cgminer#30
Add script to make mostly static linux builds. decred/cgminer#31
Have git ignore more temporary files. decred/cgminer#32
Add message at the end of build script. decred/cgminer#33
Add cross-compiling for windows build script. decred/cgminer#34
Bump for v0.1.0 decred/cgminer#35
~10% speedup decred/ccminer#1
Use decred specific version number. decred/ccminer#2
Add script to make mostly static linux builds. decred/ccminer#3
Add message at the end of build script. decred/ccminer#4
Bump for v0.1.0 decred/ccminer#5

Posted: 4/30/2016 3:45:58 AM Edited: 4/30/2016 5:59:33 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Development Roadmap and Goals update -  05/2016


Hello everyone,

The developers have put forward a development roadmap for the software that details short-term, medium-term, and long-term goals. These are actionable goals, many of which already receive active development, but they are considered actionable as development activity in these directions will produce the stated outcomes, which users will see, be able to use, and benefit from in the software.

In the drafting of this development roadmap, it was important not to forecast too far into the future, so that Decred may remain versatile and adaptable to changing conditions in the field. Users can have confidence that these goals are on the developers' minds as they continue working toward them and will begin taking form as progress manifests in the different areas. Attainment of these goals will lay a very strong foundation both through the software and the project upon which to continue building and eventually expand into new areas.

All of these goals aim to work together to establish Decred as a global decentralized network and platform for accessible representation through collective voting and consensus-based decision-making on issues. And that's where it starts.

Short-term (Current) Goals
  • Sync in the new database from btcd to prepare for voting on hard and soft forks.
  • Integrate existing Decred consensus rules into the new format inherited from btcd.
  • Demonstrate voting on a simple hardfork.
  • Clean up codebase, extend test coverage, better integrate new btcd features that were quickly merged in.
  • Clean up cryptographic libraries and remove the interface from chainec. Instead, use simple wrappers to reduce overhead.
  • Integrate latest Bitcoin softforks.

  • Speed up calls that are heavily used by dcrstakepool, such as getstakeinfo.
  • Add new RPC functionality to the gRPC interface, preparing it for general use.

  • Make voting simple and easy to use across platforms, from the stake pool to the wallet.
  • Create a website to track voting and easily display information about voting to the end user.
  • Create the initial Decred Assembly and begin making decisions to steer development in public.

  • Finish the GUI for Windows and polish the externals for presentation.
  • Wire in stake related components of the GUI.
  • Create a one click file to setup and start the GUI, with Tor integration for connectivity.
  • Add a simple functionality to look up and update the daemon and wallet if a new version comes out.

  • Speed up stakepool by using asynchronous calls to the various wallets.
  • Handle situations in which the wallets are desynced without causing failure.
  • Allow external modification of the server's state, e.g. allow triggering maintenance mode.

Scripting language and IDE
  • Finalize the specifications and syntax for the scripting language.
  • Complete the initial implementation of the scripting language, with emphasis on optimization and ease of use.
  • Ensure the scripting language is backwards compatible with Bitcoin scripting, so that the entire Bitcoin-derived ecosystem benefits.

  • Get gominer functional and into production across multiple platforms.
  • Create specifications and a proof-of-concept implementation for a new mining protocol based on stratum.

Medium-term (3-6 Months) Goals
  • Discuss and implement new opcodes to further extend the functionality of the scriping language.
  • Implement multipeer syncing.
  • Design specifications and an implementation for a merkle tree tracking the UTXO set, to enable very fast syncing.

  • Separate voting into its own independent process, similar to dcrticketbuyer.
  • Discuss and add basic privacy features, such as single use accounts and merge avoidance.

Scripting language and IDE
  • Have scripting language IDE functional. Integrate new opcodes into the scripting language.

Long-term (6+ Months) Goals
  • Investigate low-cost bidirectional sidechains that operate as PoS chains feeding from the main chain. Discuss the integration of other popular scripting languages or advanced privacy features on a PoS sidechain.
  • Begin integration of the Golang implementation of the Lightning Network.
  • Discuss the application of smart contracts to governance, and building a traditional corporate structure aided by smart contracts. If possible, transfer the development subsidy funds to more decentralized ownership.

Decred Project

Source: Development Roadmap

Posted: 7/19/2016 6:50:07 AM Edited: 7/19/2016 6:57:13 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.1.6 released - release notes below
This development dispatch covers work completed since the Decred v0.1.5 release from June 7th, 2016. Since then, developers have merged 16 pull requests of code into 3 software repositories (for changes, see below). v0.1.6 includes a new tool, dcrinstall, to automate the install, upgrade, and setup process for the Decred software.

dcrinstall: https://github.com/decred/decred-release/releases/tag/v0.1.6
Binaries: https://github.com/decred/decred-binaries/releases/tag/v0.1.6

  • Fixed an issue with memory alignment on 32-bit architectures (269-2bbfd5f)
  • Fixed an issue that interferes with the new dcrinstall package when checking if .dcrd exists (270-fa72e21)
  • Added a simnet option to the config file (272-e6beeb6)
  • Updated versioning (271-9279321)

  • Moved prompting of passphrases and seed to a prompt package so other tools can call the same prompts (268-b3bd20e)
  • Modified the wallet package to import the database driver directly (269-f2a12cf)
  • Added a non-internal prompt package (273-dfb6bcd)
  • Fixed a build error for the test harness (274-697443a)
  • Updated documentation (275-7bdd976) and versioning (271-1ca9472)


Developer Notes

dcrinstall is a tool to automate the install, upgrade, and setup process for the Decred software. In install mode dcrinstall downloads the latest released binaries of dcrd, dcrwallet, dcrctl, and dcrticketbuyer for your operating system and platform, installs them, sets up the config files, and creates a wallet for you. In upgrade mode, dcrinstall replaces your binaries with the latest copies but makes no changes to your configs.

Upgrading an existing installation

The following steps are required to upgrade a system with Decred that was not installed by dcrinstall. If you already have Decred installed you will need to follow these instructions the first time.

The dcrinstall tool expects the following directory layout. In order to upgrade you must copy your current configuration files into the correct location and ensure everything still works. You may also want to copy you executables to the directory dcrinstall expects as well.

If dcrinstall detects all configuration files it'll operate in upgrade mode. Upgrade mode only overwrites the binaries in %HOMEPATH%\decred (or ~/decred on a UNIX type OS). The dcrinstall tool records all actions in %HOMEPATH%\decred\dcrinstall.log (or ~/decred/dcrinstall.log on a UNIX type OS).

Windows configuration files:


Binaries directory:


OSX configuration files:

~/Library/Application Support/Dcrctl/dcrctl.conf
~/Library/Application Support/Dcrd/dcrd.conf
~/Library/Application Support/Dcrticketbuyer/ticketbuyer.conf
~/Library/Application Support/Dcrwallet/dcrwallet.conf

Binaries directory:


UNIX configuration files:


Binaries directory:


Run the software

Now that you have the files where dcrinstall can find them you can download and run dcrinstall. For Windows open a cmd.exe window then:

cd %HOMEPATH%\Download

For OSX and UNIX you will also need to make the file executable before runnning it:

cd Downloads/
chmod u+x dcrinstall

and your installation will be upgraded to the latest released version.

Clean install

If you are doing a clean install (no existing Decred configuration files) you can just run dcrinstall and it will setup and configure all the binaries. For Windows open a cmd.exe window and:

cd %HOMEPATH%\Download

For OSX and UNIX:

cd Downloads/

You will be asked to provide a passphrase for you wallet and given the opportunity to use and existing wallet seed if you have one.

Log file

dcrinstall saves a log file with information on everything it did which you may examine if you need more information. On Windows the file is located at:


On OSX and UNIX the file is located at:


Running Decred programs

On Windows open cmd.exe


One OSX and UNIX like systems:

cd decred/

Alternatively you can add the directory to your path. For Windows see http://www.computerhope.com/issues/ch000549.htm For OSX and UNIX refer to the documentation for your shell.

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.


dcrinstall can only install Decred releases v0.1.6 or later (although as described above it can be used to upgrade from an older version). dcrinstall has been tested on Windows 10, Windows 7, OSX 10.11, Bitrig current, OpenBSD, Fedora, Ubuntu, and Raspbian. Due to an issue with the go cross-compiler, binaries are not available for linux-arm64. Users running Linux on arm64 should either build from source or contact the Decred developers for a binary for that platform.

Posted: 7/19/2016 6:54:58 AM Edited: 7/19/2016 6:55:37 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred have a new update out v0.3.0



This development dispatch covers work completed since the Decred v0.3.0 release on July 22, 2016. Since then, developers have merged 62 pull requests into 7 repositories (see below for more detailed changes).

Here are direct links to the Windows installers for Paymetheus:

Installer: https://github.com/decred/decred-release/releases/tag/v0.3.0
Binaries: https://github.com/decred/decred-binaries/releases/tag/v0.3.0

The main feature of this release is stake purchasing and related screens in the Paymetheus GUI. Also notable are various improvements (such as GPU selection) in gominer. Various other bugfixes and improvements to the command line tools are also included.

For more information on stake mining see the docs site.


  • Make "add account" button nonexecutable when running. (PR#125)
  • Point to correct repo for the binary release. (PR#134)
  • Better error message for failed dcrd RPC connections. (PR#138)
  • Run dcrwallet RPC server on non-standard ports. (PR#139)
  • Kill any leftover wallet processes using the nonstandard port. (PR#140)
  • Show "published" message directly in create tx view. (PR#141)
  • Sync dcrwallet grpc protospec. (PR#143)
  • Explain how fees are calculated since this isn't really obvious. (PR#144)
  • Hide last generated address when opening request view. (PR#145)
  • Protect access to the shared Wallet structure. (PR#146)
  • Update to latest gRPC. (PR#147)
  • Clean up shell view styles (PR#148)
  • Fix the synchronization task to wait on the next tx/block event. (PR#149)
  • Add new stake related views (PR#151)
  • Bump for v0.3.0 (PR#152)
  • Make it explicit that Paymetheus does not vote. (PR#153)
  • Display pubkeys of generated addresses. (PR#155)
  • Avoid crash after importing a script. (PR#156)

Credits: @jrick, @ceejep, @jcv


  • rpc: Add blockheight to getstakeinfo results (PR#282)
  • config: Add txfee and ticketfee to available config settings (PR#285)
  • rpc: fixes high reported missed counts when sstrx are first issued (PR#287)
  • Fix panic when getting StakeDifficulty if dcrd disconnected (PR#302)
  • Add transaction hash to PublishTransactionResponse. (PR#304)
  • Switch doco links to point to the Decred repo. (PR#306)
  • Update to latest gRPC. (PR#308)
  • Recommend the latest glide releases over the dev version. (PR#309)
  • Save logs to the specified appdata directory. (PR#310)
  • waddrmgr: check extended pubkey network when creating a WoW. (PR#312)
  • rpctest - Fix wallet RPC port, and lots of docs and formatting. (PR#313)
  • Bump for v0.3.0 (PR#316)
  • Add public key address to next address response (PR#317)
  • If tx fee increment is unset, it should be the default (PR#318)
  • Fix lockup by breaking UTXO notifications (PR#319)

Credits: @ay-p, @ceejep, @jrick, @chappjc, @dhill, @jcv


  • Docs: Major update to home README (PR#278)
  • dcrctl: fix reading from stdin in terminal mode (PR#294)
  • Rpcserver: Account for block votes in coin supply (PR#296)
  • Rpcserver: searchrawtx - update coinbase output (PR#299)
  • Blockmanager: current() for testnet should check blockchain timesource. (PR#302)
  • Remove --addrindex option. (PR#305)
  • Add another mainnet checkpoint, add initial testnet checkpoints (PR#307)
  • Fix the coin supply calculation (PR#309)
  • Return from syncMiningStateAfterSync if peer disconnected. (PR#310)
  • Bump for v0.3.0 (PR#312)
  • Create appdata directory before writing config. (PR#313)

Credits: @ay-p, @dhill, javed-khan, @jcv, @jolan, @ceejep, @jrick


  • Use glide to manage dependencies. (PR#38)
  • Add all options to sample config. (PR#39)
  • Correct workdata comment. (PR#40)
  • Reconnect to pool if no usable target is provided. (PR#42)
  • Create stratum and work packages. (PR#43)
  • Add locks to racy data structures. (PR#46)
  • Fix benchmark mode. (PR#47)
  • Fix check for userSetWorkSize. (PR#51)
  • Clean up logging. (PR#53)
  • Add device selection/restriction. (PR#54)
  • Reorganize some functions/packages. (PR#56)
  • Add import that wasn't seen after last rebase. (PR#57)
  • Bump for v0.3.0. (PR#58)
  • Fix mining when no device is specified (PR#59)

Credits: @jcv, @jolan, @chappjc


Credits: @jcv


  • Fix cross-platform builds (PR#52)
  • Switch to v0.3.0 (PR#53)

Credits: @moo1337, @jcv

Web wallet (copay)

  • Sync with upstream (PR#20)

Credits: @ay-p

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.


The Decred installer will only work on Windows 7 and above.

Posted: 8/24/2016 9:20:53 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred related projects updates from their blog

from JAKE YOCOM-PIATT ON https://blog.decred.org/2016/08/17/Current-Projects/ 

Currently, the major projects underway are

  • Paymetheus, a native Windows GUI for dcrwallet
  • gominer, a cross-platform PoW mining client
  • Web Wallet, a fork of BitPay’s Copay stack
  • Synchronizing the btcd database rewrite to dcrd
  • Adding support for more gRPC API calls to dcrwallet


Posted: 8/24/2016 9:33:38 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.4.0 Released 2016-09-06

Dd-16 V0.4.0 (09/06/16) - https://forum.decred.org/threads/dd-16-v0-4-0-09-06-16.3998/

# Dd-16: V0.4.0 (09/06/16)


This development dispatch covers work completed since the Decred v0.4.0 release on August 15, 2016. Since then, developers have merged 49 pull requests into 8 repositories (see below for more detailed changes).

Here are direct links to the Windows installers for Paymetheus:

Installer: https://github.com/decred/decred-release/releases/tag/v0.4.0
Binaries: https://github.com/decred/decred-binaries/releases/tag/v0.4.0

This release contains improvements and bugfixes for all of the decred tools (dcrd, dcrwallet, gominer, and Paymetheus). Notable changes include Paymetheus starting dcrd automatically in the background. This is also the first release to include desktop versions of the Copay GUI for OSX and Linux. This is also the first release built with the version 1.7 of the go compiler. This produces smaller and faster binaries than previous versions of go.


  • Make seed copyable, Fixes #154 (PR#160)
  • Add Launcher project to start dcrd and open PM when finished. (PR#163)
  • Remove help link since it links nowhere. (PR#164)
  • Bump for v0.4.0 (PR#166)
  • Update assembly info for Launcher. (PR#167)
  • Fix arches for release builds (PR#168)
  • Add proper icons. (PR#169)
  • Finding correct paths for both wallet and dcrd. (PR#170)

Credits: @moo1337, @jrick, @jcv


  • Add address argument to consolidate (PR#323)
  • Add golang 1.7 and drop golang 1.5 support. (PR#324)
  • RFP-10 Milestone 1 (PR#326)
  • Wallet: limit the tx size with compressWallet/consolidate. (PR#327)
  • Update project dependencies. (PR#329)
  • Update dcrd dependency. (PR#330)
  • Fixes #146: added RWMutex on addrPools map (PR#331)
  • Bump for v0.4.0 (PR#332)

Credits: @chappjc, @dhill, @jrick, javed-khan, @jcv


  • dcrd: Do not send a wakeup if not sleeping (PR#314)
  • Travis: Add go 1.7 and drop go 1.5 support. (PR#318)
  • Add pipes for parent process IPC. (PR#311)
  • Backport #333 (Use correct r.err in dcrdLog.Errorf msg) (PR#334)
  • Bump for v0.4.0 (PR#335)
  • add more checkpoints for upcoming release (#329) (PR#338)

Credits: @dhill, @jrick, @ay-p, @jcv


  • Partial fix for proper invalid share accounting (PR#60)
  • Add license for OpenCL bindings (PR#65)
  • Make the autocalibration/device/intensity/worksize flags consistent (PR#68)
  • Some cleanup to appease go clean/go vet (PR#69)
  • Fix build on 32-bit platforms and properly error on too small worksizes (PR#70)
  • Properly account for multiple OpenCL platforms (PR#71)
  • Cleanup atomic usage. (PR#74)
  • Remove erroneous waitgroup Done in Stop (PR#76)
  • Bump for v0.4.0 (PR#77)

Credits: @jolan, @dhill, @jcv


  • Fix typos (PR#36)
  • Fix misses first buying opportunity (PR#40)
  • make consistent with other dcr tools and repair web UI (PR#41)
  • Update glide.yaml (PR#43)
  • Add heightCheck to make sure that purchase is run once per height (PR#44)
  • Document maxinmempool is the number of your, not all, tickets. (PR#45)
  • Fix price mode issues (PR#46)
  • Update MaxPerBlock check to match comment above (PR#47)
  • Update couldBuy to reflect number of possible tickets left in window (PR#48)
  • Load previously used toBuyDiffPeriod from purchased.csv (PR#49)
  • Bump for v0.4.0 (PR#50)
  • Revert config file name change and add back in httpuipath for compat (PR#51)

Credits: @jolan, javed-khan, @dhill, @ay-p, @jcv


  • Update for dcrticketbuyer changes (PR#56)
  • Change defaults for v0.4.0 (PR#57)

Credits: @moo1337, @jcv


  • Comment out ionspinner and ion infinite scroll due to CPU/mem usage (PR#27)
  • Update package.json and github release api URL (PR#30)
  • Update icon and allow window resizing (PR#32)

Credits: @ay-p

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.


The Decred installer will only work on Windows 7 and above.

Posted: 9/12/2016 12:39:12 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.5.1 released! Development Dispatch 17, installers, and binaries are now available.


# Dd-17: V0.5.0 (10/10/16)


This development dispatch covers work completed since the Decred v0.4.0 release on September 06, 2016. Since then, developers have merged 102 pull requests into 9 repositories (see below for more detailed changes).

Here are direct links to the Windows installers for Paymetheus:

Installer: https://github.com/decred/decred-release/releases/tag/v0.5.1*
Binaries: https://github.com/decred/decred-binaries/releases/tag/v0.5.1*

* 0.5.1 was released with a dcrwallet bug fix for upgrading from very old wallet versions. Paymetheus users can safely use 0.5.0.

All users are strongly encouraged to upgrade to this release.

This release contains bugfixes and improvements to all of the decred tools (dcrd, dcrwallet, gominer, Copay, and Paymetheus). A new unified database for tickets and blocks has been added to dcrd. This provides significant performance and reliability improvements. gominer now supports NVIDIA GPUs using CUDA. gominer can now monitor temperatures and fan speeds on supported AMD or NVIDIA GPUs. The dcrd codebase has been modified to track the upstream btcd project more closely, allowing for easier copying of code between the two projects. Additional rpc tests have been added to dcrwallet (RFP-10). All changes since the last release are listed below.


Credits: @moo1337, @jrick, @jcv


  • RFP-10 Milestone 2 (PR#336)
  • Improve wallet atomicity. (PR#339)
  • rpctest: fix appdata vs datadir issue (PR#342)
  • Return previously-ignored errors in waddrmgr. (PR#346)
  • Bump for v0.5.0 (PR#347)
  • Fix namespace passed to wstakemgr API. (PR#348)
  • Can't range over a slice being modified. (PR#349)
  • Normalize addresses in all waddrmgr APIs. (PR#352)
  • Update dcr* deps glide.lock for 0.5.0 (PR#356)

Credits: @chappjc, @jrick, @jcv, @ay-p


  • Do not error if dcrctl can't find dcrd.conf. (PR#339)
  • Reconcile btcd and dcrd auto generated config file semantics (PR#341)
  • Fix a bug with invalidating blocks in new DB and add more sanity checks (PR#343)
  • dcrd: Fix another upgrade issue. (PR#346)
  • add another checkpoint for mainnet and testnet (PR#348)
  • Replace the ticket database with an efficient, atomic implementation (PR#349)
  • Fix a bug indexing addrindex when blocks are invalidated (PR#353)
  • Synchronize to the merging of btcd PR 666 (PR#358)
  • Sync to btcd commit '5a1e77bd2dd6f5302a82d3d27b4e3a60526918b1' (PR#359)
  • Merge in btcd commit 3b39edcaa1e867efc4223d95ca1496aaadf8eca3 (PR#360)
  • travis: goclean (PR#361)
  • deps: Update to latest commits. (PR#362)
  • Merge in btcd commit e15d3008cfd59756db9570da9e47da6831313196 (PR#364)
  • Merge in btcd commit b87723cd94ea11c29e22c4372ba4fe96886e7c83 (PR#366)
  • Merge in btcd commit 644570487f379e9856ae4025181ecc6293d86711 (PR#367)
  • Merge in btcd commit de4fb243899fc988cb3f320bbec9bee95966691b (PR#368)
  • Merge in btcd commit 27c0f9f8d1af6a44423b03a2e4f03d4a87a1ac40 (PR#369)
  • Merge in btcd commit e7ddaa468e5a699a9c21136e3d453ce38034b98a (PR#370)
  • Merge in btcd commit b14032487f67ac140606e7b5f4cd4781243c62c7 (PR#371)
  • Merge in btcd commit 1b234102147901738bb79b2edf2d803225a36d57 (PR#372)
  • Merge in btcd commit 0d7f52660096c5a22f2cb95c102e0693f773a593 (PR#373)
  • Merge in btcd commit f893558d782396f10c2fe49a8bc73deff4a36d14 (PR#374)
  • Merge in btcd 7f07fb1093dd80105d36d61c8fb8a16f6e9d9b29 (PR#375)
  • Merge in btcd commit dc83f4ee6a127038dc0238600bdc745d239cf8b1 (PR#376)
  • Merge in btcd commit f68cd7422dd5d0e0d6002647305c1fd663aee77d (PR#377)
  • Merge in btcd commit 5de5b7354ca458d6e7677d6b4629214d3f871b59 (PR#379)
  • Merge in btcd commit 2adfb3b56acd280e84451e94dd0c06203eef9832 (PR#380)
  • Merge in btcd commit 6229e3583505a82d4514b1efa86f910b78693825 (PR#381)
  • Remove unused ErrBIP0030 (PR#385)
  • Bump for v0.5.0 (PR#390)
  • add more checkpoints for release (PR#396)
  • Fix a bug for forced reorganizations (PR#392)
  • blockchain: remove unnecessary check. (PR#400)
  • Update dcr* deps for 0.5.0 (PR#401)
  • Fix a bug reloading the blockchain (PR#402)
  • Version the JSON-RPC API with semantic versioning. (PR#387)
  • stake: Correct prng uint32 rollover. (PR#403)
  • Improve the order of the context free tests (PR#404)

Credits: @dhill, @moo1337, @jolan, @ay-p, @jcv, @ceejep, @davecgh, @jrick


  • Hook up travis (PR#)
  • Print leading zeros in target difficulty. (PR#79)
  • Initial support for cuda mining. (PR#81)
  • Bump for v0.4.1 (PR#85)
  • Small optimization for CUDA. (PR#88)
  • adjust various headers so windows builds (PR#89)
  • add result field so errors are unmarshaled properly (PR#90)
  • gofmt (PR#91)
  • fix cgo Go pointers issue (PR#92)
  • move deviceListIndex increment back to the right spot (PR#93)
  • Clean up some old or incorrect comments. (PR#95)
  • use nvml to fetch fan and temperature information (PR#96)
  • Fix the size of data copied from device. (PR#99)
  • implement amdgpu sysfs support to fetch fan and temperature information (PR#100)
  • fix using a device on the second OpenCL platform (PR#102)
  • use a slice of submitIDs instead of a single submitID (PR#103)
  • Jcv split (PR#105)
  • implement ADL support to fetch fan/temperature information (PR#106)
  • Implement CUDA on windows, Fixes #108 (PR#109)
  • Remove some unused and unneeded code (PR#112)
  • Remove unneeded word in INFO log line (PR#114)
  • add automatic fan control to maintain a target temperature (PR#115)
  • Improve cpu usage with CUDA. (PR#116)
  • add some default Windows CFLAGS/LDFLAGS and remove unixy code (PR#117)
  • Update sample config with all new options. (PR#119)
  • add more Windows details and some general improvements (PR#120)
  • Bump for v0.5.0 (PR#126)

Credits: @jolan, @dhill, @jcv, @moo1337, @jrick


  • Add additional code to fix ticket left in window check (PR#53)
  • purchase: handle updated balance in purchase window (PR#55)
  • Bump for v0.5.0 (PR#61)
  • Update dcr* deps for 0.5.0 (PR#65)

Credits: javed-khan, @ay-p, @jcv


  • remove last reference to webui (PR#59)
  • Add -version flag (PR#61)
  • don't need to copy directories anymore; fixes windows upgrade race (PR#62)
  • Implement downloadonly flag. (PR#64)
  • show output by default and add quiet option (PR#66)
  • Bump version and defaults for v0.5.0 (PR#67)

Credits: @moo1337, @jcv, @jolan


  • Update all logos and icons (PR#)
  • Update so backup confirmation sorts properly and shows uppercased words (PR#44)
  • Fix several places where the desktop version conflicts with upstream. (PR#45)

Credits: @ay-p, @jcv

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.


The Decred installer will only work on Windows 7 and above.

Posted: 10/18/2016 4:36:40 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.6.0 released! Development Dispatch 18, installers, and binaries are now available.


# Dd-18: V0.6.0 (11/09/16)


This development dispatch covers work completed since the Decred v0.5.0 release on October 10, 2016. Since then, developers have merged 42 pull requests into 8 repositories (see below for more detailed changes).

Here are direct links to the Windows installers for Paymetheus:

Installer: https://github.com/decred/decred-release/releases/tag/v0.6.0
Binaries: https://github.com/decred/decred-binaries/releases/tag/v0.6.0

This release contains bug fixes and improvements for dcrd and dcrwallet.

A new block test framework has been added to simplify adding new tests. 380 new block tests have been added with it.

Several RPC improvements have been made. A number of voting related fixed and improvements have been made to support future voting changes.

dcrwallet now processes transactions atomically.

gominer and copay are unchanged. Paymetheus is unchanged but should be updated for the updated dcrd and dcrwallet dependencies.


  • Add SetBalanceToMaintain (PR#35)
  • Add ExistsExpiredTickets to dcrrpcclient (PR#36)
  • Add methods to use the new version and getheaders RPCs. (PR#37)
  • Setticketsvotebits (PR#39)
  • Updates for dcrd JSON-RPC websocket API changes. (PR#40)

Credits: @chappjc, @ay-p, @jrick


  • Add expired to getstakeinfo command (PR#360)
  • Update dependencies, including 3rd party ones. (PR#361)
  • Update the wallet to begin allowing extended votebits setting (PR#362)
  • Fully update PoolTickets when using AddTicket rpc (PR#365)
  • RFP-10 milestone 3 (PR#369)
  • Bump for v0.6.0 (PR#373)
  • Correctly handle both p2sh and p2pkh addrs in wstakemgr. (PR#376)
  • Process transactions atomically with connected blocks. (PR#372)
  • Remove Wallet.ChainSynced/SetChainSynced APIs. (PR#378)

Credits: @ay-p, @jrick, @ceejep, @chappjc, @jcv


  • Output of --help/-h should go to os.Stdout rather than os.Stderr (PR#386)
  • Fix the dumpblockchain function (PR#405)
  • Use correct function to fetch blocks from the blockchain for RPC (PR#407)
  • Remove unused files (PR#408)
  • Prevent high memory usage when turning txindex on first time (PR#412)
  • Add a block pruner that only prunes occassionally (PR#415)
  • dcrctl: fix output in --terminal mode (PR#416)
  • Add existsexpiredtickets to rpcserver (PR#418)
  • Replace some unnecessary dcrutil.Tx usage with wire.MsgTx. (PR#419)
  • Add voting version parsing function (PR#420)
  • Add dcrjson decode func for concatenated hex hashes. (PR#421)
  • Add new setticketsvotebits command (PR#422)
  • Add func to decode string hashes to a passed destination. (PR#425)
  • Add getheaders JSON-RPC extension command. (PR#426)
  • Add EncodeConcatenatedHashes with test. (PR#432)
  • dcrctl: Set width to max in --terminal (PR#436)
  • blockchain: Add block validation infrastructure (PR#437)
  • Bump for v0.6.0 (PR#438)
  • Update 3rd party deps in glide (PR#439)
  • Add StakeVersion to header. (PR#441)
  • Use same notification for mined transactions and blocks. (PR#434)
  • Update dcrrpcclient for dcrctl. (PR#445)
  • update checkpoints (PR#446)
  • Notify only relevant stake txs, not all. (PR#447)

Credits: @chappjc, @ceejep, @dhill, @ay-p, @jrick, @davecgh, @jcv, @moo1337


  • Update onBlockConnected to match upcoming change in dcrd (PR#73)

Credits: @ay-p

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.


The Decred installer will only work on Windows 7 and above.

Posted: 11/15/2016 7:04:36 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Upgrading Consensus (posted on the Decred blog 2016-11-16)
Over the next few releases, Decred will enable Proof-of-Stake (“PoS”) miners to vote on proposed consensus changes.
This voting will allow Decred users to exercise sovereignty over whether or not to accept hard fork changes, in addition to making other important decisions.

Upgrading Consensus https://blog.decred.org/2016/11/16/Upgrading-Consensus/

Upgrading Consensus

Upgrading Consensus


Over the next few releases, Decred will enable Proof-of-Stake (“PoS”) miners to vote on proposed consensus changes. This voting will allow Decred users to exercise sovereignty over whether or not to accept hard fork changes, in addition to making other important decisions. Enabling this decision making requires versioning several subsystems: block headers, vote transactions and transaction scripts. Versioning these subsystems allows for reliable and relatively smooth hard forking on an ongoing basis, meaning Decred can continuously upgrade its consensus code provided the PoS miners agree with each of the changes. Further, we have added a series of full-block consensus tests that are automatically run on every pull request to the consensus daemon, dcrd. Before this process can commence, we must implement a soft fork to add and enforce vote transaction versioning, and enforcement will occur as part of the next release, 0.7.0. Decentralizing the larger-scale decision making is the first step of several towards making Decred into a robust and fully operational decentralized autonomous organization (“DAO”).

Versioning consensus

The consensus code in any cryptocurrency is the most important and most delicate code in its codebase. Correspondingly, this consensus code is the real “magic” that makes a blockchain possible: without this shared set of rules about what is and is not considered an acceptable block or transaction, a decentralized ledger cannot have a reliable distributed timestamp. As such, the consensus code can comfortably be considered the most interesting part of a cryptocurrency, however, most projects are extremely conservative about modifying consensus code because it is so delicate and typically necessitates a hard fork. Some projects, e.g. Bitcoin, go so far as to avoid hard forks under all circumstances, and instead opt for routine use of soft forks. Based on what we’re doing with Decred, we obviously don’t agree with soft forks as a means to upgrade consensus, mainly because it breaks the social contract that comes with a blockchain, but that is a whole separate blog entry.

Instead of treating consensus code as a “delicate snowflake” that is only to be touched if absolutely necessary, we have instead chosen to figure out how to reinforce the snowflake and make it more resilient. Part of this reinforcement process is a system whereby all pull requests to dcrd, the consensus daemon, are subjected to automated full-block consensus tests and will not be merged to master until those tests pass. The full-block tests use a separately-coded test harness that allows for crafting custom blocks on demand to test branch conditions in the consensus code. In some ways, this could be viewed as making a “cast” of the snowflake and ensuring each change to dcrd’s code does not break that cast. By having this battery of tests run on consensus code, we can be confident that both existing and new consensus code is stable and will not create unplanned forks.

Going from one set of consensus rules to another requires signaling via versions in several subsystems. Some of the changes required are pretty obvious, like having a version in the block header, but the others are less obvious, e.g. adding versions to vote transactions and transaction scripts. The block header and vote transaction versions signal that Proof-of-Work (“PoW”) and PoS miners are on the latest version, which means PoW and PoS miners will both have the latest set of consensus rules and votebits enabled. The votebits, part of every vote transaction, encode what issues are currently being voted on by stakeholders. Transaction script versioning is required because you must know the script rules for old pay-to-script-hash (“P2SH”) transactions, which may not be spent until some time in the future. While transaction script versioning is important, the important parts for consensus versioning are the block header and vote transaction versions.

Soft fork: vote versioning and version enforcement

Stepwise versioning consistent with the block header for network consensus rules has been added to votes. We will be soft forking to add the vote transaction versioning and begin enforcing a particular version once 95% of both the block headers and votes show the new version in a rolling 144 block window. Blocks and votes with a version less than the latest version will be accepted until 95% of the blocks and votes both (separately) have the latest version, at which point nodes will begin to reject blocks and votes with any version less than the latest one. The vote versioning has been added in the 0.6.0 release and enforcement of the block header and vote versions will occur starting with version 0.7.0. With the soft fork complete, the process of upgrading consensus can begin.

Upgrading to a new consensus rule set

Once the versioning soft fork is complete and activated, it means that a supermajority of the users in the Decred network who validate blocks are upgraded to the latest version. By signaling the latest version of consensus, these PoW and PoS miners confirm that they have the latest definition of the votebits and the corresponding conditional logic to implement any consensus changes, assuming a given consensus change is voted in. After a new consensus version is activated, the voting process begins and runs for 8064 blocks, which is approximately 28 days. Over this period, up to 40320 votes are cast on the various issues encoded in the votebits for the current version. Issues receiving 75% or greater ratios of “yea” to “nay” votes over the voting period are considered approved and will go into effect after a lock-in period of 8064 blocks after the end of that voting period. Once the end of the lock-in period is reached, the issues that were approved in the prior voting cycle go into effect, meaning that consensus changes take effect at that point. This lock-in period is intended to allow users of Decred some additional time to upgrade their full nodes before the blockchain hard forks. The choice of parameters for the voting period, lock-in period and approval ratios was intentional and deserves some explanation.

Consensus upgrade path
Consensus upgrade path

The voting period was chosen to allow for nearly a full ticket pool worth of votes, 40320 tickets, to vote, but not be so long that it would drag for several months. By having the voting period be 8064 blocks, we allow 40320 votes to be cast, which is roughly a full cycling of the ticket pool. Further, 28 days is an acceptable length of time over which to allow voting: it is neither too short nor too long a period. Similarly, the lock-in period was chosen to be 8064 blocks since it is also neither too long nor too short and gives users a reasonable amount of time to upgrade their full nodes. This means that consensus changes take 2-3 months to be encoded in votebits, voted on and activated.

Choosing a 75% threshold for approval of an issue being voted on is based on considerations for the costs of creating a long-lived fork of Decred. In order to have a properly functioning blockchain, there must be a single chain that has only relatively short-lived forks, or else users cannot determine which transactions and blocks are valid and which are not. Decred’s hybrid PoW/PoS consensus requires that blocks must be mined by PoW miners and then voted on by PoS miners, which makes voting on hard forks not only possible but rather stable. If we assume there are 2 forks of Decred, call them F and F’, where F’ uses a newly approved set of consensus rules and F uses the previous set of consensus rules, we can use the PoS approval threshold, call it P, to derive an expression for the orphan rate of blocks on F, the “old” chain, as a function of P. This function, graphed below, shows that if we require an approval threshold, P, equal to 75%, it means that the orphan rate for blocks on F is approximately 90%.

Orphan probability

This orphan rate effectively drives up the cost of PoW mining on fork F by a factor of 10, and this is assuming 100% of the hash power were to stay on fork F. In practice, this means that attempts to create a long-lived fork of Decred by a minority of dissenting stakeholders will have a drastically (10x or greater) increased cost of maintaining the chain. For other PoW-based cryptocurrencies that have a long-lived fork, such as Ethereum, the only financial barrier to a fork is a short term reduction in the speed with which blocks are mined. By having a high financial barrier to maintaining a long-lived fork, Decred ensures that spirited dissent does not lead to divisive forking of its blockchain.

While many cryptocurrency projects are content to decentralize only select components of their system, Decred will continue pursuing decentralization as a process to build a more robust and distributed ecosystem. By formally including stakeholders in the decision making process on an ongoing basis, Decred is creating a truly multipolar system where users are governed only with their explicit cryptographic consent. We will be announcing a longer term roadmap for this process in the near future since making decisions on what constitutes consensus is only one step in the process. A major milestone in this process will be a proper DAO, built without the pitfalls associated with attempting to encode a DAO into a single monolithic smart contract.

Posted: 11/17/2016 6:59:24 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Dd-20: V0.7.0 (12/26/16)

Decred v0.7.0 released! Development Dispatch 20, installers, and binaries are now available.


# Dd-20: V0.7.0 (12/26/16)


This development dispatch covers work completed since the Decred v0.6.0 release on November 09, 2016. Since then, developers have merged 187 pull requests into 10 repositories (see below for more detailed changes).

Here are direct links to the Windows installers for Paymetheus:

Installer: https://github.com/decred/decred-release/releases/tag/v0.7.0
Binaries: https://github.com/decred/decred-binaries/releases/tag/v0.7.0

decrediton Linux: https://github.com/decred/decred-bi...ad/v0.7.0/decrediton-0.7.0-linux-amd64.tar.gz
decrediton OSX: https://github.com/decred/decred-binaries/releases/download/v0.7.0/decrediton-0.7.0.dmg

This release contains bug fixes and improvements for dcrd, dcrwallet, and Paymetheus.

This includes the first release of decrediton, a new, cross-platform GUI for decred. This is not a feature complete version of decrediton. Simple operations (creating wallet, importing a seed, sending and receiving decred) are supported. This is primarily a demo of decrediton rather than a production ready tool. Please try it and report any issues or additional features you would like on the [github page](https://github.com/decred/decrediton/issues). Currently binaries are only provided for 64 bit Linux and OSX.

Paymetheus has added seed restoration as well as the ability to show rescan progress.

dcrd has various bugfixes and infrastructure improvements for voting in a future release.

A new rpc command to resync has been added to dcrwallet. The functionality from dcrticketbuyer has been added to dcrwallet. See this commits for details on using the new functionality instead of the seperate dcrticketbuyer binary.

gominer and copay are unchanged so there are no new binaries for them. You should use the previous release for either of them.


  • Updates for dcrd JSON-RPC websocket API changes. (PR#40)
  • Fix return result type for Version(Async) RPCs. (PR#41)
  • Switch goclean to use metalinter. (PR#43)

Credits: @jrick and @jcv


  • Refactor to integrate pkg ticketbuyer for automated ticket purchases (PR#374)
  • Remove Wallet.ChainSynced/SetChainSynced APIs. (PR#378)
  • Fix a bug in the semver compatibility check. (PR#380)
  • Update dependencies. (PR#381)
  • Add Rescan RPC to the gRPC server. (PR#382)
  • Marginally clean up acct/addr discovery code. (PR#383)
  • Update gRPC client doco for changed requirements. (PR#391)
  • Fix an improperly formatted error found by Travis. (PR#396)
  • Update dcrutil version (PR#398)
  • Add controlled startup RPCs to the gRPC interface. (PR#399)
  • Sp fix (PR#400)
  • Move decision to send attached block notifications to caller. (PR#403)
  • Catch up version on main branch (PR#408)
  • Change WalletService.GetTransactions to return stream. (PR#409)
  • Improve error handling by ignoring less errors. (PR#410)
  • Correctly handle duplicate blocks in the main chain. (PR#413)
  • Require seed parameter for LoaderService.CreateWallet RPC. (PR#415)
  • Name WalletLoaderService correctly in documentation. (PR#417)
  • Remove database if wallet.Loader.CreateNewWallet errors. (PR#419)
  • Update JSON-RPC help. (PR#422)
  • Disable broken tests so working tests can be run. (PR#423)
  • Reenable tests on travis. (PR#424)
  • Remove internal/legacy/* packages. (PR#427)
  • Add links to WalletLoaderService Methods (PR#428)
  • Pull in latest dcrd version. (PR#429)
  • Implement the rescanwallet JSON-RPC. (PR#430)
  • config: add --piperx (PR#432)
  • Remove cmd/dropwtxmgr and doco references to it. (PR#434)
  • Actually require the wtxmgr namespace to exist. (PR#435)
  • Fix --create by creating the transaction manager. (PR#437)
  • Remove -v from go test on travis. (PR#438)
  • Update decred deps to pull in new dcrutil. (PR#440)
  • Add tlscurve option to specify TLS curve. (PR#442)
  • Fix possible exceptions in example gRPC clients. (PR#445)
  • Use atoms, not Satoshis, in example clients. (PR#447)
  • Add gRPC SeedService. (PR#449)
  • Change --profile to take a listen address (or many). (PR#450)
  • Allow --piperx=0 (stdin). (PR#452)
  • Add WalletService.ConstructTransaction RPC. (PR#455)
  • Verify that addresses are intended for the active net. (PR#457)
  • ticketbuyer: Stop purchaser on client shutdown (PR#469)
  • Allow running either the new or old ticket buyer. (PR#470)
  • Serialize calls to ticketbuyer Purchase. (PR#472)
  • Revert change to default ticketmaxprice option. (PR#475)
  • ticketbuyer: Fix set split tx, ticket fees (PR#478)
  • ticketbuyer: Fix use of maxpriceaabsolute, txfee (PR#479)
  • Improve efficiency of triggering the ticket buyer. (PR#480)
  • bump wallet vote version to 3 (PR#461)
  • Update internal glide deps for 0.7.0 (PR#486)
  • Bump for v0.7.0 (PR#459)

Credits: javed-khan, @jrick, @jcv, jzbz, @ay-p, @dhill


  • blockchain: simplify logic in checkCoinbaseUniqueHeight (PR#440)
  • ErrBadStakevaseScrVal -> ErrBadStakebaseScrVal (PR#444)
  • blockchain: remove redundant check (PR#449)
  • blockchain: pruneStakeNodes never returns an error (PR#450)
  • Glide update at the beginning of 0.7.0 (PR#458)
  • blockchain: Remove unnecessary RuleError.GetCode. (PR#459)
  • travis: 1.7 -> 1.7.3 (PR#460)
  • peer: use atomics instead of mutexes (PR#461)
  • peer: Extract protocol negotiation from main read and write loops (PR#462)
  • blockchain: Associate time src with chain instance. (PR#463)
  • wire: Export transaction tree constants. (PR#464)
  • blockchain: optimize HaveBlock (PR#465)
  • wire: Consolidate tests into the wire pkg. (PR#466)
  • multi: Upstream chainhash abstraction sync (PR#467)
  • blockchain: LogBlockHeight only needs a wire.MsgBlock.. (PR#471)
  • multi: Upstream parameter abstraction sync (PR#473)
  • dcrd: Simplify shutdown signal handling logic sync. (PR#474)
  • license: add title (PR#475)
  • txscript: Expose AddOps on ScriptBuilder. (PR#476)
  • docs: Add chainhash to README.md (PR#477)
  • server: Remove superfluous check in OnMemPool. (PR#478)
  • mempool: Optimize the votes map slices. (PR#479)
  • stake/dcrjson: Simplify code with gofmt -s. (PR#480)
  • server: Optimize get mining state code. (PR#482)
  • mempool: Remove exported InsertVote function. (PR#483)
  • mempool: Rename GetVoteHashesForBlock & remove err. (PR#484)
  • mempool: Decouple mining-specific logic. (PR#486)
  • stake: Convert TxType constants to enum syntax. (PR#488)
  • multi: Restore correct upstream majority version code. (PR#490)
  • Bump to v0.6.1 (PR#492)
  • rpcserver: Return RPC errors from block template. (PR#494)
  • mempool: Refactor mempool code to its own package. (PR#496)
  • dcrjson: Add rescanwallet JSON-RPC request. (PR#500)
  • Add unit tests. (PR#504)
  • Fix typo. (PR#505)
  • Remove -v from go test. (PR#507)
  • Pull in latest dcrutil. (PR#508)
  • add more checkpoints for upcoming release (PR#509)
  • Test another failing condition in validate.go (PR#511)
  • Fix output formatting in a unit test. (PR#513)
  • blockchain: Make params used in tests match. (PR#517)
  • fullblocktests: Limit tickets to target pool size. (PR#518)
  • fullblocktests: Generate subsidy for voted block. (PR#519)
  • Implement stake voter version interrogation command. (PR#522)
  • rpc: Add missing StakeVersion to getblock verbose (PR#529)
  • Implement softfork mechanism. (PR#524)
  • Validate softforking consensus rules (PR#526)
  • Bump for v0.7.0 (PR#515)

Credits: @dhill, @moo1337, @ay-p, @davecgh, @jrick, @jcv, @jolan


  • Bump for v0.6.1 (PR#77)
  • Remove -v from go test. (PR#80)
  • Bump for v0.7.0 (PR#81)

Credits: @jcv


  • Decrediton hello world, from electron-quick-start example on github (PR#2)
  • Add in basic rigging and some button PoC (PR#4)
  • Fix README.md typos and errors. (PR#6)
  • Initial framework commit. (PR#7)
  • Fix grpc client connectivity and get balance button click PoC (PR#9)
  • Update README.md for accurate deving (PR#10)
  • Add rough cut of LoginForm and rigging in place to share grpcClient (PR#11)
  • Strip down react/redux to basic components to build up from (PR#12)
  • Add webpack configs from electron-react-boilerplate (PR#16)
  • First major introduction of bootstrap and various other front end pieces (PR#17)
  • Update package.json for decrediton and packaging (PR#18)
  • Update .gitignore (PR#23)
  • Add sidebar and proper login/getbalance state handling (PR#25)
  • Add WalletLoaderService functionality to prepare wallet for actions (PR#35)
  • Reenable ssl for grpc. (PR#38)
  • Use .decrediton instead of .dcrwallet (PR#41)
  • Launch dcrd and dcrwallet on startup. (PR#43)
  • Fix possible exception in cert load. (PR#46)
  • Correct app name and menu links. (PR#47)
  • Set version to something more reasonable. (PR#48)
  • Use decred icon instead of default in packages. (PR#49)
  • Combine duplicate code for rpc cert loading. (PR#51)
  • Finish boilerplate for redux/grpc calls (PR#52)
  • Change babel-core version back to 6.18.2 due to 6.20.0 breaking (PR#53)
  • Add basic boilerplate/impl of grpc notifications to actions (PR#54)
  • Add final boilerplate for grpc control (PR#55)
  • Various fixes for control api and first pass on receive page (PR#56)
  • Move config options to file instead of hardcoding. (PR#58)
  • Explicitly set rpc ports for dcrd. (PR#62)
  • Add eslint with basic rules. (PR#63)
  • Add material-ui React component implementation remove react-bootstrap (PR#66)
  • Remove leftover grpc binary (PR#67)
  • Add eslint-formatter-pretty back. (PR#69)
  • Start on cleaning up based on eslint. (PR#72)
  • Address more lint issues. (PR#74)
  • Add some basic instructions to the README (PR#77)
  • Use the same license all over. (PR#79)
  • Add constructTransaction and loadActiveDataFilters gRPC (PR#80)
  • Make port in README.md match defaults in code. (PR#88)
  • GetStarted funnel revamp, plus lots of other fixes (PR#89)
  • Remove passphrases from redux state (PR#90)
  • Construct/Sign/Publish tx split apart and given proper forms (PR#91)
  • Adds button on Home page to allow for users to start rescan (PR#95)
  • Add CircularProgress components (PR#97)
  • Add SeedService to allow for new seed generation and existing seed processing (PR#98)
  • Add VersionService to ensure that decrediton is running on expected dcrwallet version (PR#99)
  • Rough first pass to display getTransactions (PR#103)
  • Add disclaimer for initial release (PR#111)
  • Allow packaged app to find api.proto. (PR#115)
  • Update README for mac. (PR#117)
  • Bump for v0.7.0 (initial release) (PR#92)
  • Fix path to dcrd directory on macOS and windows. (PR#120)

Credits: @ay-p, @jcv, @dhill

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.


The Decred installer will only work on Windows 7 and above.



Posted: 1/9/2017 1:20:43 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred has released their roadmap for 2017

(Source: https://blog.decred.org/2017/01/09/2017-Decred-Roadmap/)

2017 Decred Roadmap

2017 Decred Roadmap


The time for a new Decred roadmap has finally arrived. While many users have been keen to know where the project is headed in detail, we have intentionally avoided laying out our longer term plans in order to prevent other projects from implementing these ideas before they make it into Decred. I recognize that our approach with Decred runs counter to most other cryptocurrency projects, which often focus much more on hype and marketing than on development and sound engineering. Instead of hyping future work in advance of its completion, we have quietly completed our work and will hype it as it goes into production. Now that we are close to our first major post-launch milestone, hard fork voting, it is a good time to share where Decred will go from here. Here is a summary of what we have planned for Decred in 2017:

  • Convert Decred into a stakeholder-directed DAO - While other projects have attempted to create a DAO via a monolithic smart contract, Decred will build a DAO in several steps, ensuring each component works independently before putting it into production.
    • Hard fork voting - Stakeholders will be able to vote on all hard fork changes to Decred, with only those changes obtaining greater than 75% support being activated.
    • Public proposal system - After hard fork voting is in production, we will create an off-chain system where Decred users can submit proposals for future work to be performed by the development organization, Decred Holdings Group (“dev org” or “DHG”).
    • Decentralized control of DHG funds - Currently, the control of DHG funds is centralized, and this will be resolved by creating a system whereby control of these funds is decentralized, e.g. based on stakeholder voting.
  • Lightning Network support - The lightning network is the most directly useful application of smart contracts to date since it allows for off-chain transactions that optionally settle on-chain. This infrastructure has clear benefits for both scaling and privacy.
  • Improved GUI wallets - We have made substantial progress with GUIs, Paymetheus (Windows) and decrediton (Windows, OS X, and Linux), and will continue to improve the user experience.
  • RFP process change - To date, the RFP process has involved giving quotes on deliverable sets, and this system is cumbersome to administrate and maintain. The RFP process will change to one where individuals and businesses will be contracted on a longer term basis to work for the project. As part of the RFP changes, we will be looking for contractors to do marketing, advertising, documentation and community management work.
  • Presence at events - With hard fork voting nearly ready for production, we have some legitimately interesting content to discuss at events. Our presence at events will ramp up starting in late Q1 2017.
  • Enhanced privacy - Starting in late Q2 or early Q3 2017, we will propose a new initiative to enhance user privacy.
  • Payment integration support - Instead of only focusing on Decred from a speculative position, we will support efforts to integrate Decred as a payment method for businesses starting in Q1 2017.

Each of these roadmap items is discussed in greater detail below.

Hard fork voting

Bitcoin demonstrated that it is possible to disintermediate the storage and transmission of value, an area that is the mainstay of the banking industry. Decred will demonstrate that it is possible to disintermediate the process of political decision-making for a cryptocurrency, something that typically requires an elected or appointed official. Allowing stakeholders to vote on all hard fork changes ensures interested parties have representation in major decisions that will affect Decred, unlike most other cryptocurrencies. The ability to implement ongoing user-approved hard fork changes will give Decred the ability to continuously adapt and evolve.

This ability to hard fork on an ongoing basis with stakeholder support is key to the decentralized governance that was proposed as part of our February 2016 launch. In terms of relative difficulty, this hard fork voting is the highest hurdle to cross since it deals with consensus code, which is notoriously brittle and challenging to write. Instead of knocking out the easier more visible tasks first, we have opted to clear the most difficult hurdle first and move to unlock what we see as the most valuable part of Decred. We will have a hard fork voting demo for the coming 0.8.0 release, to be followed soon after by a set of hard fork changes to be voted on in the next release.

Public proposal system

Once hard fork voting is working, a natural question to ask is “how do you decide on what to vote on?”, which several astute users have pointed out is currently a centralized process. We are aware that the decisions about what the dev org should work on and what issues get voted on are centralized, and fixing this is a further step towards decentralization of the dev org. Setting up a system where users can submit proposals for what to work on, fund or vote on is a good way to start.

The proposal infrastructure will be public and off-chain but will be anchored to the Decred chain. A formal proposal for the software used for this will be made public following hard fork voting going into production. Getting the proposal system into production should only take a few months and be relatively easy in comparison to the hard fork voting work.

Decentralized control of DHG funds

In order to complete the transition from a centralized dev org, DHG, to a decentralized autonomous organization, the Decred DAO, control of the dev org funds must be decentralized. This will be the last step required before DHG can be dissolved and dev org funds transferred to the Decred DAO.

As the Ethereum Project has learned first-hand, bugs or exploits that affect control of a DAO’s funds can create a very serious problem. Instead of entrusting the funds to a contract that is Turing complete, we will design, implement and test a simple non-Turing complete smart contract that decentralizes the control of funds. One possible route to take here is to make disbursements of funds from the dev org require generic stakeholder approval, but this and any other proposed solutions will need to be examined from a legal and tax perspective.

Lightning network support

The Lightning Network (“LN”) that builds on top of Bitcoin is the best proposed use of smart contracts I have seen to date. LN uses minimally-complex non-Turing complete smart contracts to facilitate off-chain transactions, which is something that all cryptocurrency projects should consider supporting from both a scaling and a privacy perspective. Once enabled, this will allow atomic cross-chain transfers between Decred, Bitcoin and any other project that supports LN, creating a new low-latency low-risk liquidity channel for Decred.

Since Decred is still rather close to Bitcoin in terms of code, it should be straightforward to sync code from btcd to dcrd that will enable the various opcodes and other soft fork changes required to support LN. Instead of activating these changes via soft forking, as was done in Bitcoin, we will activate these changes via hard fork voting, so our stakeholders will have the opportunity to make the decision to activate LN support.

Improved GUI wallets

In the past several months, we have made substantial progress with our wallet GUIs, Paymetheus (Windows) and decrediton (Windows, OS X, and Linux). Decred is based on btcsuite, so it did not have the luxury of inheriting an existing well-used GUI, unlike many projects based on bitcoin-qt In the next few releases, all the major functions performed by dcrwallet, the command line wallet, will be made available in Paymetheus and decrediton, e.g. using a stakepool, automatic purchasing of tickets and voting support.

The next release will feature substantial improvements to decrediton, which is currently in an alpha state and not recommended for non-technical users. All basic wallet functions will be working the 0.8.0 release of decrediton, and possibly some of the more advanced features. As part of hard fork voting, graphical components will be added so that users can easily set their voting preferences without dealing with the command line in both Paymetheus and decrediton. After the wallet GUIs are “caught up” with dcrwallet’s features, we will move onto integrating multisig, the proposal system and LN support.

RFP process change

The original prescription for distributing dev org funds was one based on deliverable-driven requests for proposal (“RFPs”). In some cases this deliverable-driven process worked out rather well, but in others it led to complete inaction on part of the contractors. What has become clear is that a deliverable-driven process makes sense for certain types of work and not for others. For example, design work and sysadmin/infrastructure tasks work well on a deliverable-driven basis, while development, documentation, marketing and community management require continuous work over longer periods of time. In order to make progress on these fronts, we need to find individuals or businesses that are independently motivated and can steadily deliver while being paid in decred.

Having identified the problems with the RFP process from this first iteration, we will begin searching for contractors who are interested in performing ongoing work in the areas of development, documentation, marketing and community management. Since DHG pays out in decred, a typical contractor would work on the project on a part time basis, submitting a monthly invoice where DHG is billed on an hourly basis, with some maximum billable number of hours per week. The weakest areas are the community management and marketing, so we will turn our attention to staffing those areas first. Specifically, we’re looking for people who can help maintain and drive participation on the Decred Forum, Slack, Twitter, bitcointalk, reddit and other relevant forums and sites.

Presence at events

With hard fork voting going into production in the next 2 releases, Decred will have unique infrastructure for modifying its consensus rules on an ongoing basis, which provides plenty of material for a talk or presentation at conferences. Previously, it could be argued that Decred did not provide a particularly strong value proposition for its users, but with hard fork voting, that value proposition becomes concrete. Decred will continue ceding sovereignty over its various functions to the stakeholders as we continue to pursue decentralization as a process, and each step of that process will be something that can be presented and discussed.

Ensuring Decred has a presence at various cryptocurrency conferences and events will be a priority starting in late Q1 2017. In the meantime, we will publicly and collectively prepare a list of events to attend, either as attendees or as speakers. I am aware that there is a political dimension to getting speaking time at conferences, so anyone who can help us get speaking time should make a point to get in touch via the forum. Based on my experience going to Bitcoin conferences over the past several years, I have learned it is very easy to burn a lot of money attending events, so we will need to be cautious with expenditures in this area.

Enhanced privacy

The attentive Decred user may have noticed that most of us at Company 0 are pretty serious about privacy and security (see the previous zkc entry), so it should be entirely unsurprising to hear that we have plans to enhance privacy in Decred. To date, several larger cryptocurrency projects have focused on privacy, e.g. Monero, Dash and Zcash. Based on the level of competition amongst the various privacy-centric projects, we decided to avoid competing in this domain, at least in this early phase of Decred. In late Q2 or early Q3 2017, we will begin publicly developing a new method of enhancing privacy for Decred.

Since the cryptocurrency privacy domain is so competitive, I will not be sharing any details on what we have planned. It will be a substantial departure from what is currently in use by other projects, so it should make for a decent surprise.

Payment integration support

Cryptocurrencies are intended to be used as a system for both the storage and transmission of value, so it is only natural to support the integration of Decred in the context of transmitting value. Giving merchants the ability to accept decred as payment or to spend it with their vendors creates utility, liquidity and value for Decred. The integration work needed to support Decred can take many forms, e.g. WooCommerce plugin, supporting fiat-to-decred exchange, or adding support to an existing payment processor. Integration work for accepting payments in decred will require several groups of people collaborating: merchants, implementors, developers and payment processors.

Initially, it is ideal to isolate support to the larger platforms and more technical merchants, e.g. top e-commerce solutions, larger altcoin payment processors and more technologically adept merchants. An ideal scenario for a payment integration would have the following properties:

  • The merchant is sufficiently technologically adept to use and nominally understand Decred.
  • The merchant is located in a jurisdiction with a volatile currency and/or capital controls, e.g. Venezuela, so that Decred’s volatility is less of an issue.
  • The merchant routes some portion of their sales and/or purchases via Decred.
  • The merchant and their counterparty are in jurisdictions where other individuals or businesses can assist with fiat-to-decred (or vice versa) liquidity.
  • The merchant uses decred as a store of value.
  • The merchant makes larger transactions in decred.

While it’s obviously not possible for every interested merchant to satisfy this checklist, it serves to demonstrate the ideal scenario where Decred and merchants can mutually benefit from payment integration. If you own a business and are interested in using decred as a payment method or store of value, come interact with us on the forum to see what your options are. We will begin discussing what integration work to start with on the forum this week and merchants can expect several options to be available by end of Q1 2017.

In conclusion

After quietly grinding on Decred for the past several months, we are at the point where we are preparing hard fork voting infrastructure that is both unique and decentralizes much of the control over the project typically retained by the project developers and founders. We look forward to making decentralized decisions with our stakeholders and building a stakeholder-directed Decred DAO. The roadmap presented above is comprised of tangible components, most of which will be completed in 2017. Some of the goals presented are of an ongoing nature, e.g. payment integration, enhanced privacy, and RFP refinements, so those will reappear in future roadmaps. If you have any questions, ideas or comments about this roadmap, I encourage you to comment in the forum thread.

Posted: 1/16/2017 5:54:56 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v0.8.0 released! Development Dispatch 21, installers, and binaries are now available.

(Source: Dd-21: V0.8.0 (02/13/17) - https://forum.decred.org/threads/dd-21-v0-8-0-02-13-17.5111/)


This development dispatch covers work completed since the Decred v0.7.0 release on December 26, 2016. Since then, developers have merged 140 pull requests into 9 repositories.

Here are direct links to the Paymetheus GUI wallet installers:

decrediton cross-platform GUI wallet installers:

dcrinstall cross-platform text-based CLI installers:

all the various binaries except for dcrinstall:

NOTE: All Windows binaries only support Windows 7 and newer.

A lot has happened in the past several weeks since the 0.7.0 release of Decred. On the valuation front, the exchange rate has gone up substantially from a low of approximately USD 0.43 on December 28th to an all-time-high of USD 3.31 on February 5th, which has since settled around USD 2.50. The number of downloads of binaries from GitHub for the 0.7.0 release has gone up by a factor of 5 or more, and we have a substantially larger number of users in Slack and other chat channels. This substantial improvement in valuation, exposure and community engagement is due mainly to our recent work with several marketing contractors via the dev org, DHG, which I will say more about below.

Beyond matters related to Decred's valuation, there has been substantial progress on several of our software projects and with their documentation. The bulk of the code needed to enable hard fork voting has been completed, and it will be demonstrated live on testnet over the next few weeks, via a corresponding website that shows its progress. A substantial design overhaul has been completed during the past several months, which includes a new logo and changes to every project website. decrediton, the cross platform GUI, has made a huge amount of progress, going from an alpha project to a solid beta in a single release. Paymetheus, the native Windows wallet, now uses the new stakepool API integration to simplify setting up ticket buying with a stakepool. Several additions and updates have been made to the Decred documentation site by documentation contractors. More detailed descriptions of our progress can be found below.

Marketing, Documentation and Development Contractors

Per the recent 2017 Decred Roadmap, a deliverables-driven RFP process did not end up working out very well, so we have since changed our RFP process to be need-driven by domain. The dev org, DHG, has contracted 5 people to do marketing, 2 to do documentation and 3 to do development work. So far, this arrangement is working out very well and has led to substantial progress on the marketing and documentation fronts.

The marketing contractors have met with considerable success in increasing awareness, engagement and generally creating demand for decred. The puzzles created by @coin_artist have been particularly effective at drawing new users to our Slack channels and creating a general buzz about Decred. The efforts of @Daniel, @Emilio Mann, @Tivra and @Dyrk have served to grow our community, engage new users, create additional demand, support regional markets and broaden our social media support. Overall, this marketing work has been very successful to date.

The documentation and development contractors have started doing work more recently, so they haven't had as much time as the marketing contractors to get their deliverables flowing. @gratefulcheddar and @Shadowlance have been pushing out a lot of new and updated documentation over the past few weeks, and their output should become much more apparent over the next few months as they shore up the Decred documentation. @karamble has pushed out a lot of web development work in the past couple weeks, which has made an otherwise monolithic release much more manageable. @raedah has submitted several pull requests that improve dcrwallet's ticketbuyer, which should lead to improvements in the fee market for tickets. We expect the contributions from our documentation and development contractors to become more apparent in the coming months.

Substantial Design Update

A design overhaul of Decred was initiated in RFP-7 several months ago with @linnutee, and it is being brought to completion with the 0.8.0 release. The work includes a new logo, design updates for every project website and a branding package for other Decred-related projects to use. As you can imagine, updating every website the project maintains is a pretty daunting task, so beyond @linnutee and sander doing all the design and coding, we had @karamble integrate and audit their work, and @Shadowlance contributed text copy in several places.

For those who are interested in the details of this work, I recommend you give @linnutee's recent Medium post a read.

Hard Fork Voting Demo

While it's certainly less tangible than a surge in the exchange rate, the core of Decred is based around decentralization as a process, and the first major step in that process, hard fork voting, has been prepared for a demo on testnet. Stakeholders will soon have the ability to vote on defined issues in dcrwallet, and this will allow Decred to episodically hard fork based on how its stakeholders vote. If 75% or more of the stakeholders vote “yes” for a given issue during a voting period, it will go into effect approximately 4 weeks later (on mainnet), and this includes “hard fork” consensus changes. Getting this code ready has been particularly challenging since it is all consensus-related code, which is notoriously unforgiving when it comes to bugs.

The testnet demo has an accompanying webpage that allows users to watch each step in the voting process occur. We chose to have a single issue for the demo, to increase the block size from 1 MiB to 1.25 MB, and we felt this was appropriate since the block size has been so contentious for Bitcoin. There are 3 stages to hard fork voting, which is reflected on the demo website, and this process draws from some parts of the BIP0009 soft fork process from Bitcoin. First, Proof-of-Work miners must update their dcrds to the latest release until a threshold percentage, 75% in the case of testnet, of blocks in a rolling window show the new block version in their header. Second, Proof-of-Stake miners, i.e. stakeholders, must update their voting wallets to the latest release of dcrwallet until a threshold percentage, 75% for testnet, of votes in blocks in a fixed window show the new vote version. At the end of the first interval with 75% or greater support for the new vote version, the stake version is incremented to the new version and a voting period begins. Once a voting period comes to an end, any issues that receive 75% or greater 'yes' votes are considered complete and will become active after a lock-in period. Issues that receive 75% or greater 'no' votes are considered dead and will not be voted on further. If an issue does not receive a 75% or greater vote either direction, the issue remains up for voting in future voting periods until an expiration time is reached. The process of upgrading PoW miners, PoS miners and voting will occur on an ongoing episodic basis and allow Decred's consensus code to evolve over time, according to the will of its stakeholders. We estimate that it will take 3-6 weeks for the testnet demo to have the block size increase voted in and for the hard fork to occur, so users can stop by and check the progress on the webpage.

Major GUI Wallet Progress

Until this release, only Windows users had the option of running a self-contained GUI wallet with Paymetheus, so we are pleased to announce that decrediton, a cross platform GUI wallet, is ready for use on Linux and OS X. decrediton now supports all the basic wallet functions and delivers most of what users would expect a GUI wallet: it is simple to install, has a graphical setup wizard, can restore from existing wallet seeds, and can send and receive payments. Considering that the 0.7.0 release of decrediton was in a very much “alpha” state, this release constitutes a huge leap forwards in terms of improved user experience.

Beyond the decrediton progress, Paymetheus has added support for a new stake pool integration API, which simplifies the process of using a stake pool with Paymetheus. Once a user has registered an account at a stake pool, they can copy an API key from their stake pool login into Paymetheus, and then Paymetheus handles the rest of the stake pool setup. Prior to adding this API to stake pools, the user would have to generate a pubkey, copy and paste it to the stakepool, hit a button, and then copy and paste the multisig address back into Paymetheus. We had originally wanted to make even signup for a stake pool possible via this API, however, this created an obvious Denial-of-Service vector and had to be removed. The new process for using a stake pool is much less error prone and avoids confusion on part of users, so it is a notable improvement.

By the next release, both Paymetheus and decrediton will support automatic ticket buying and have an interface for users to set their voting preferences. Between this release and the next, we will make minor releases that include these new features in the GUI wallets, so that users can test them and give us feedback. We will announce these minor releases and provide updated binaries to make it easy for everyone to test out the new features as they are added.

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.

Posted: 2/17/2017 3:16:53 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

0.8.2 Decred Patch Release (for Testnet Only!)


We just dropped the 0.8.2 patch release for testnet. During code review for an unrelated feature, we ran across vote accounting bug. As we went down the rabbit hole we found some other inconsistencies. We, therefore, decided to create a patch release that addresses all the items. The bugs were squashed, the inconsistencies fixed and we added a bunch more test code to hit all that new code.

We apologize for the churn but we felt strongly enough that we needed these fixes in the wild. So please take the time to update all your 0.8.0 binaries to 0.8.2 if you are running or playing with testnet.

Download it here: https://github.com/decred/decred-binaries/releases/tag/v0.8.2

This release ONLY affects testnet. Mainnet only users do not need to update!

Posted: 2/17/2017 3:28:07 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v1.0.0 has been released today



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:

decrediton (OSX, Linux) GUI wallet installers:

dcrinstall cross-platform text-based CLI installers:

all the various binaries except for dcrinstall:

NOTE: 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:

  1. whether or not to use a new ticket price algorithm
  2. 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.


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

Posted: 4/26/2017 10:57:29 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred, The World’s First Fully Democratic Cryptocurrency Platform, Receives an Upgrade - Bitcoinist.com




· APRIL 30, 2017 · 12:00 PM


Decred is a cryptocurrency project and platform built with the sole purpose of granting its participants the power to guide the ecosystem. This democratic design eliminates the possibility of interference from separate entities or governments.


The much-anticipated recent release of Decred v1.0 marks the beginning of direct community consensus voting. Decred will be the first cryptocurrency to reappropriate its governing control away from a centralized authority to the community of stakeholders. Usually, the control lies in the hands of miners and developers, but with Decred, it is distributed among the community members to ensure that everyone’s views and votes play a role in shaping the ecosystem.

Decred utilizes a hybrid proof-of-work and proof-of-stake consensus system. It allows the platform to strike a balance between the benefits to both miners and stakeholders, offering a much more complete form of consensus.

Decred Democratic Cryptocurrency Platform


The new Decred v1.0 release will change the required percentage for stakeholder approval to a minimum of 75% vote for consensus change and one signaling vote. There has been recent fluctuation in the ticket price, due to an increased number of stakeholders, which has been attributed to the cryptocurrencies recent spike in adoption.

This fluctuation exemplifies the project’s need for a majority community consensus to resolve such issues. The first vote will be on Decred v1.0’s new ticket price algorithm designed to diffuse large ticket price fluctuations and provide an improved ticket price discovery while maintaining a consistent ticket pool size.

The second vote will allow stakeholders to signal support for Lightning Network development. The Lightning Network will bring the platform the ability to process super-fast payments with an economical fee structure to all users. Should the vote pass, Decred developers will integrate the Lightning Network on the blockchain and once fully operational, a future consensus vote can be initiated to activate the Lightning Network code automatically.

Decred has also released its 2017 roadmap, highlighting an improved proposal system that will allow for the community to contribute directly to the platform’s future agenda.

Decred Autonomy Puzzle Challenge


Decred is celebrating version 1.0.0 release with a puzzle challenge. The ‘Autonomy Puzzle’ challenge features a prize of 500 decred (DCR) to the first solver, equivalent to approximately USD 7,500 at the time of this release.

The value of Anatomy Puzzle’s prize will reduce during every 24-hour interval. The puzzle’s difficulty level is set in the range of ‘easy to medium,’ so that everyone can participate in it. For more specific details or to join the puzzle solving conversation, visit the Decred Slack channel #puzzles.

More information about the latest version of Decred and its Autonomy Puzzle is available in its most recent press release.

Posted: 4/30/2017 5:08:58 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v1.03 has been released



This development dispatch covers work completed since the Decred v1.0.1 release on April 29th, 2017. Since then, developers have merged over 150 pull requests into 8 repositories.

Here are direct links to the Paymetheus (Windows) GUI wallet installers:

Decrediton (OSX, Linux) GUI wallet installers:

dcrinstall cross-platform text-based CLI installers:

All the various binaries except for dcrinstall:

NOTE: All Windows binaries only support Windows 7 and newer.

This patch release primarily focused on UI/UX changes to the Paymetheus and Decrediton GUIs with improvements in ticket purchasing, address generation and rescanning, and passphrase management. In the backend, dcrwallet received a number of database enhancements and performance boosts as well better error handling. Progress was also made in dcrd with better block and error handling. For those interested in the technical details of all changes that occurred in the codebase, please consult the release notes.

The following changes may be of interest to users and are of note:


  • It is no longer possible to set a public passphrase when creating a wallet, and if a public passphrase was set on an existing wallet, users are given the opportunity to remove the passphrase. This change was made because the public passphrase was not effective and became a nuisance to many users.
  • The Purchase Tickets view is now simply called Tickets and has been slightly modified to provide a better user experience. The split transaction fee setting has been removed from this view and labels on some of the other settings have been modified to make the options more understandable.
  • There is now a button in the Tickets view to create ticket revocations. If a stakepool fails to vote or the vote is not included in a block by miners, and the pool also does not issue a revocation transaction, users can create the revocations themselves directly from the GUI.
  • When importing scripts, it is now possible to start a rescan for all additional relevant transactions involving the script. This means that stakepool users restoring from seed will no longer need to drop down to the command-line tooling to fix their wallets.
  • With the recent increase in Decred's value, default transaction fees have been dropped from 0.01 DCR/kB to 0.001.


  • It is now possible to import scripts into a Decrediton wallet. This will help users who are restoring from seed or transitioning from another wallet and also use a stakepool see their balance properly.
  • The ability to issue ticket revocations has been added to the ticket page for cases where a stakepool does not vote or the vote is not included in a block.
  • Log files can now be viewed using the system file browser from a menu item to help users debug or see issues.
  • The private passphrase on a wallet may now be changed from within Decrediton.
  • The rescan and address discovery features have been improved to speed up import and startup and prevent possible balance confusion.

Special Event

This release also coincided with the first ever Decred Ask Me Anything (AMA) event on Reddit. If you missed the AMA, you are welcome to enjoy the archived thread of the DCR team and community with special guest and lead developer @davecgh on the Decred subreddit. Thank you to @Noah, pvtwarren, and @Tivra for helping put it together!

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.


As always, thank you to the great contributors who made this release possible: Arriu, @ay-p, @chappjc, @dhill, @jcv, @jolan, @jrick, and @peterzen.

Posted: 6/18/2017 4:59:02 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred launches decentralized voting process for blockchain protocol changes


Decred launches decentralized voting process for blockchain protocol changes

Christine Chiang, 17 Jun 2017

Decred recently announced a proposal system that allows users to participate in governance, a major milestone in the projects road map. Allowing stakeholders to vote on changes ensures interested parties have representation in major decisions that will affect the cryptocurrency.

“The ability to implement ongoing user-approved hard fork changes will give Decred the ability to continuously adapt and evolve,” states the organizer of the Decred project Jake Yocom-Piatt. “In terms of relative difficulty, this hard fork voting is the highest hurdle to cross since it deals with consensus code, which is notoriously brittle and challenging to write.”

“Bitcoin demonstrated that it is possible to disintermediate the storage and transmission of value, an area that is the mainstay of the banking industry. Decred will demonstrate that it is possible to disintermediate the process of political decision-making for a cryptocurrency.”

- Jake Yocom-Piatt

Jake Yocom-Piatt first announced Decred late in 2015, after spending more than 2.5 years financing and overseeing the development of an alternative full-node Bitcoin implementation, btcsuite.

Btcsuite is a fully functional alternative full node to Bitcoin Core’s reference implementation, like bcoin, libbitcoin, and bitcoinj. It is a widely respected Bitcoin library, and has been used by several high profile projects including, but not limited to, the Lightning Network, BitGo, Ethereum, and Factom.

Bitcoin had “several persistent and severe problem areas,” Yocom-Piatt said when announcing Decred, including project governance, funding development and miners having too much power. “Having rebuilt the Bitcoin infrastructure from the ground up on my own dime, I have a rather unique perspective on Bitcoin despite being late to the game.”

Yocom-Piatt subsequently turned btcsuite into Decred, and quickly implemented a hybridized governance system, a combination of the Proof of Work (PoW) system found in Bitcoin and Proof of Stake (PoS).

PoS adds an extra layer of decentralization to Decred and allows users to vote on suggested network changes. Users can supply tokens rather than using computational power to participate in votes for protocol changes. The fundamental change was based on MC2 and proof-of-activity (PoA) by Iddo Bentov, Charles Lee, Alex Mizrahi and Meni Rosenfeld.

To become a voter, users must “stake,” or purchase voting rights in the form of “tickets,” at an average cost of 50 Decred tokens (DCR) per ticket, although this price fluctuates. Staked coins can be locked up for a period of up to 6 months, ”skin in the game,” Project Manager Marco Peereboom explains.

“The proposal system is a signaling mechanism versus a rule-change mechanism. So the hard fork voting is meant to enforce new consensus rules whereas the proposal system is going to be more of a signaling to indicate to the development organization that the community wants a particular feature implemented.”

- Marco Peereboom

The network token, DCR, was introduced without having fundraised using the now highly popular Initial Coin Offering (ICO) model. The first 840,000 Decred native tokens, DCR, were “airdropped” to 3,244 recipients. The airdrop simply distributed tokens to participants who had registered.

There are currently 5.1 million coins in circulation out of a total 21 million possible coins in existence. The block subsidy works the same way as Bitcoin in the sense that newly minted coins are rewarded every few blocks. The difference is, rather than having 100% of the block rewards go to the miners, 60% go to the Proof of Work miners, 30% go to the Proof of Stake holders, and 10% go to the development organization (DHG) which will ultimately become a DAO.

The concept of hybridizing PoW and PoS consensus mechanisms creates a stratification of consensus between PoW miners and PoS miners. PoW miners are needed to generate the blocks that build the blockchain and PoS miners are needed to ensure that PoW miners create blocks that are consistent with the desires of the users of the currency.

“In order to create a sustainable system of governance, we have created a project Constitution and extended the notion of consensus hybridization to apply more generally as one of several layers in a stratified consensus system. This stratification allows various groups of stakeholders to have representation at various consensus layers.“

- Jake Yocom-Piatt

If the maximum block size issue were raised in the context of a hybridized PoW/PoS system, PoS voters can force PoW miners to support the agreed on changes. In the context of contentious issues like maximum block size changes, this gives a clear resolution to the dispute via the PoS voters.

The PoS holders can force consensus changes by invalidating PoW blocks that go against the new consensus rules, removing the incentive for PoW miners to behave without regard for PoS holders.

“A very rough analogy here would be that PoW is to PoS as banks are to their depositors, so what this hybridization of PoW and PoS has created is analogous to a bank that actually acts according to the will of its depositors,” Yocom-Piatt explains. “In my opinion, this substantially improves on the system we currently have in Bitcoin, where holders of bitcoin have no say in the consensus process.”

This ability to change the protocol on an ongoing basis with stakeholder support is key to the decentralized governance that was proposed as part of the official Decred launch in February 2016.

While attempting to achieve true decentralization, the core developers are trying to remove themselves from the project, transferring decision-making power from the current top-down model to a bottom-up model driven by the community that their protocol supports.

“Instead of knocking out the easier more visible tasks first, we have opted to clear the most difficult hurdle first and move to unlock what we see as the most valuable part of Decred.”

- Yocom-Piatt

A recent vote, that had just been passed, marked a significant moment in Decred’s history. Upon voting on what would have been a highly controversial change in Bitcoin, the economic community passed a PoS algorithm change which effectively lowered the fee subsidy for its miners.

The current Decred lead developer, Dave Collins, told Brave New Coin that the algorithm drives certain behaviors, “one of those behaviors is that people compete to buy tickets….The fees go to the miners. The PoW miners are incentivized to keep the current algorithm whereas the new algorithm makes the overall process for purchasing tickets and dealing with that hybrid system much nicer. It also comes at the expense of PoW miners where they get fewer fees. There’s a conflict of interest where the PoW miners want to keep the current rules while the PoS and rest of the ecosystem want to go to the new rules.”

“In Bitcoin, there’s really no good way to solve that,” Collins states. “In Decred, we created a vote, the vote passed, it’ll activate in about a month, and we’re in the lock-in period. It’s monumental because it was a controversial change that went through and it’ll pass without any fuss.”

The voting system is part of an overarching goal to become a stakeholder directed Decentralized Autonomous Organisation (DAO), as outlined in the 2017 Roadmap. While other projects have attempted to create a DAO via a monolithic smart contract, Decred will build a DAO in several steps, ensuring each component works independently before putting it into production.

“Decentralizing the larger-scale decision making is the first step of several towards making Decred into a robust and fully operational decentralized autonomous organization (‘DAO’).”

- Jake Yocom-Piatt

The next step in achieving this goal is the Public proposal system, an off-chain system where Decred users can submit proposals for future work to be performed by the development organization, Decred Holdings Group (DHG). Developers will then start work on decentralizing control of DHG funds, by creating a system based on stakeholder voting.

The proposal system is comprised of two component products: dcrtime, a timestamping feature, and an off-chain “anchored” proposal data repository. The system draws on the work of Peter Todd’s opentimestamps, which allows a nearly unlimited number of hashes to be timestamped on a blockchain.

Proposals and their anchors, or pointers, are stored on a separate off-chain database. Anchors are then episodically committed to the blockchain. “The timestamping feature allows users to track how a proposal was submitted, when, what files were added, etc.” Peereboom explains. “We want to make sure that people can see every proposal being made, including spammy ones, to ensure we’re not silencing anybody.”

The downside to having an off-chain data store is giving up a core advantage of blockchain solutions: censorship-resistance. Off-blockchain data storage is typically done in centralized servers, which can fail or be shut down by a government. “We use a variety of strategies to deal with failures,” Peereboom explains. “Everything that can be made redundant is and we have people on staff that monitor this.”

Dave Collins states that the worst case scenario would be an inaccessible front end until the situation is resolved, “The blockchain will absolutely not depend on the off-chain system in order to function in any way, so regardless of anything that might happen on the proposal system side, the core network will continue operating as normal.”

“The anchoring process involves immutably adding the details and results of the user-based decisions to the public ledger in a compact and cryptographically verifiable fashion, so there are no privileged servers. Due to this, it will be possible for any stakeholders to independently and trustlessly prove those results regardless of the status of any ‘official’ servers there may or may not be.”

- Dave Collins

Posted: 6/18/2017 5:04:58 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

[2017-06-22] Exodus Welcomes Decred - Decred Integrates with Exodus to Offer Secure Transfer of Blockchain Assets + cryptographic challenge with USD $5K prize in $DCR


Exodus Welcomes Decred

Decred Integrates with Exodus to Offer Secure Transfer of Blockchain Assets

Extension of the DCR and Exodus Networks Comes on the Heels of a Flurry of Other Upgrades from the Cryptocurrency Industry Stalwarts

Chicago, IL June 22, 2017—Decred (DCR), the cryptocurrency for the people by Bitcoin developers, today announced that it is supported by Exodus, the first desktop multi-asset wallet app that allows users to secure, manage, and exchange blockchain assets. With this partnership, Decred participants can enjoy complete and easy control of their currency. They also enjoy full privacy on all transactions, thanks to Exodus' built-in integration with ShapeShift, an industry standard.

"We are excited to offer this extension of the DCR network," said Jake Yocom-Piatt, Project Lead, Decred. "Exodus gives our users a virtual wallet that is both user-friendly and secure. Empowering users to manage blockchain assets in a simple, one-click manner is the practical, down-to-earth use-case that is essential for the long-term growth of this industry. We couldn't be happier with this deployment."

"Written into the Decred project ethos are principles dedicated to free and open-source software, multi-stakeholder inclusivity, and incremental improvement of privacy and security," said Daniel Castagnoli, Exodus Co-Founder and Chief Creative Officer. "With a dev team that has been involved in this industry since its inception, Decred is one of the most innovative digital currencies available today. Making our platform compatible with their offering is key to reaching the broadest community of users who believe in taking control of their financial future—without banks, brokers, or institutional oversight."

The news of this integration comes on the heels of Decred's launch of decentralized voting for the blockchain. It also comes as Exodus has implemented confirmation tracking and other new features to make its wallet more user-friendly and secure to the broadest range of users.

Surprise Launch Challenge:

As a special treat, the two projects have collaborated to launch a cryptographic challenge with USD $5K prize in $DCR. Decred has a history of creating cryptographic challenges with bountiful prizes, and this event will be no different. The challenge begins at exodus.io/decred, and it will be live as of June 22 at 10 PM PDT. May the best hacker win!

The Exodus and Decred software are available for Windows, Mac, and Linux. For more information, visit: www.decred.org

Posted: 7/5/2017 7:08:31 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v1.05 has been released (2017-06-21)


This development dispatch covers work completed since the Decred v1.0.3/4 release on June 9th, 2017. Since then, developers have merged over 36 pull requests into 7 repositories.

Here are direct links to the Paymetheus (Windows) GUI wallet installers:

Decrediton (OSX, Linux) GUI wallet installers:

dcrinstall cross-platform text-based CLI installers:

All the various binaries except for dcrinstall:

NOTE: All Windows binaries only support Windows 7 and newer.

This is a patch release that primarily focuses on wallet issues and usability. All users of the GUI wallets and command line tools are encouraged to update. Mining software is not impacted. For those interested in the technical details of all changes that occurred in the codebase, please consult the release notes.


This release focuses on fixing an issue that could result in address reuse after restarting the application. If a previously created address was not publically used, it could be returned again after restarting. This issue has been corrected by always deriving the next address based on the last created one.

A database upgrade has been added to record the additional info needed to fix the above issue. Due to the database being forwards-compatible only, wallet software cannot be reverted to older versions after running a new version. If a wallet must be reverted back to old software, a seed restore should be performed.

Two new RPCs have been added to this release. The first is a revoketickets RPC which is preferable to using rebroadcastmissed, as the latter may be removed at a later time. The second is WalletService.GetTransaction for the gRPC server which queries the wallet for details regarding a particular transaction using the transaction hash. Previously, transaction details were only available by watching block notifications or querying for all transactions in a range of blocks.

Note that these wallet improvements are now available in Paymetheus wallet GUI.


This version of Decrediton includes quite a few bug fixes as well as revealing more information to users to avoid situations where a lack of information can lead to confusion. The Accounts, Send, and Receive pages have all received large redesigns. Further design improvements will take shape in future releases.

The Accounts page now includes a balance overview for each account and its respective details. The Send page received the most substantial change and no longer has a seperate transaction confirmation view. Instead, whenever a user completes an output or amount field, these are now are checked for validity and then sent to dcrwallet for transaction construction. Users can now see the estimated size, fee, and total amount in the lower right of the GUI instead of having to wait until the next page. Also, upon clicking the Send button, passphrase confirmation is asked for to enhance security. Various other smaller fixes and visual tweaks were included in this release as well to improve the overall user interface and experience.

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.


As always, thank you to the OG contributors and a newcomer who made this release possible: @ay-p, @davecgh, frankcash, @jcv, @jolan, and @jrick.

Posted: 7/5/2017 7:16:50 AM Edited: 7/5/2017 7:18:14 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred has a new release update v1.0.7 (2017-08-18)


This development dispatch covers work completed since the Decred v1.0.5/6 release on June 21st, 2017.

Here are direct links to the Paymetheus (Windows) GUI wallet installers:

Decrediton (OSX, Linux) GUI wallet installers:

dcrinstall cross-platform text-based CLI installers:

All the various binaries except for dcrinstall:

NOTE: All Windows binaries only support Windows 7 and newer.

Full release notes:


This release of dcrd primarily contains improvements to the infrastructure and other quality assurance changes that are bringing us closer to providing full support for Lightning Network.

A lot of work required for Lightning Network support went into getting the required code merged into the upstream project, btcd, which now fully supports it. These changes also must be synced and integrated with dcrd as well and therefore many of the changes in this release are related to that process.


This release focused on fixing several issues related to corrupted spend tracking that would cause double spend errors when sending transactions. All users are recommended to upgrade.

This release also lays the groundwork for more staking features to be implemented in future releases. The wallet now tracks more details about all tickets and the votes or revocations that spend them. In future releases, this can be used to implement highly requested features such as detailed listings of all tickets, votes, and revocations and subsidy calculations.

***Database upgrade notice***

This release contains a wallet database upgrade. Once upgraded, the database can not be used on older releases and downgrading will require restoring from seed or backup. The Decred project recommends ensuring you have access to your wallet seed before upgrading in case a downgrade is necessary.


This release focused on under-the-hood improvements to the backend (dcrwallet) instead of new features or UI changes. Users should no longer encounter double spend or orphan transaction errors sending transactions due to fixes for wallet spend tracking corruption, but a seed restore is necessary to fix already-corrupted wallets.


This release of Decrediton aims to smooth out various issues that users have consistently reported since the release of v1.0.6. Extra care has been taken to ensure that users get as much information as possible to understand some of the inner workings of Decred. But at the same time, ticket purchasing and other features are actively being simplified and refined. We have also added some basic animations instead of the default loading screens. We hope to integrate several pieces of art and animations from our amazing community of artists.

In the coming releases we are expecting the following: Windows releases and a completely revamped on boarding procedure. This release is a step toward realizing those goals.

We have also begun a complete refactor and reorganization of the React components which will be followed by an audit of Redux state usage. This issue describes the end goal of this project. Ideally, we will be able to make the UX/UI development open to all designers, which will allow for a true collaborative effort.

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.


I'd like to especially thank our 4 newest contributors for their work this release: peterzensndurkingo1dfishdnldd. We've seen amazing progress from them and expect big things from their continued growth. And as always the c0 devs: @ay-p@davecgh@dhill@jcv@jolan@jrick, and @marco.

Posted: 8/18/2017 9:18:01 PM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred Adds Atomic Swap Support for Exchange-Free Cryptocurrency Trading

Decred is announcing support for on-chain atomic swaps, which will allow cryptocurrency holders to trade directly, without having to rely on external exchanges. The cryptocurrencies initially supported are Decred (DCR), Bitcoin (BTC) and Litecoin (LTC).

Source:  Giulio Prisco, Bitcoin Magazine - https://bitcoinmagazine.com/articles/decred-adds-atomic-swap-support-exchange-free-cryptocurrency-trading/#1505916875 

Decred Adds Atomic Swap Support for Exchange-Free Cryptocurrency Trading

Giulio Prisco
Sep 20, 2017 10:11 AM EST

Decred is announcing support for on-chain atomic swaps, which will allow cryptocurrency holders to trade directly, without having to rely on external exchanges. The cryptocurrencies initially supported are Decred (DCR), Bitcoin (BTC) and Litecoin (LTC).

“Support for on-chain atomic swaps is extremely useful,”Jake Yocom-Piatt, Decred Project Lead said in a statement. “Thanks to the foresight of the Lightning Network authors and developers, and the dedication of our own developers, it is our pleasure to deliver an important capability that has been discussed since the concept of cross-chain atomic transfers was proposed in 2013.”

Users can already begin performing exchanges between DCR, BTC and LTC using tools that the Decred developers have created. The tools are text-based at the moment, but will be integrated into the Decrediton GUI wallet in a future release.

According to the Decred team, this advancement disintermediates the exchange process, allowing for greater market fluency. It also delivers on the market desire for improved interoperability between currencies and the demand for new efficiencies that drive investor value.

"This is the first step in a progression toward high-utility, non-Turing complete smart contracts,” Yocom-Piatt told Bitcoin Magazine. “We look forward to a new generation of greater fluency between projects. It was a pleasure collaborating with the dev teams at Litecoin and Lighting Labs."

The concept of atomic swaps (or atomic cross-chain trading) were first described by Tier Nolan back in 2013. A previous Bitcoin Magazine articleprovides a step-by-step explanation of a simple example where two users agree to swap agreed amounts of BTC and LTC and use the multisig and time lock features available in both Bitcoin and Litecoin basic scripting to synchronize two transactions on two independent blockchains without having to trust each other.


"Yesterday I did an on-chain atomic swap of 1.337 LTC for 2.4066 DCR w/ @_alyp_ of @decredproject. (See txns: https://github.com/decred/atomicswap/#first-mainnet-dcr-ltc-atomic-swap …)"⛓️⚛️💱🚀

It’s worth noting that Lightning Network payment channels, now enabled by SegWit, make atomic swaps more powerful and easier to implement, and permit adding support for off-chain swaps.

“The addition of LN support allows for both on-chain and off-chain atomic swaps, meaning that trustless cross chain exchanges can occur,” noted Yocom-Piatt. “Since supporting LN does not break any existing functionality and only adds to Decred’s capabilities as a system of value storage and transmission, it is a very attractive target for addition to Decred.”

“On-chain atomic swaps are an important step towards enabling peer-to-peer cryptocurrency trading,” said Laolu OsuntokunLightning Network Daemon (LND) lead developer. “We are excited for this process to continue with off-chain atomic swaps over the Lightning Network in the near future. By taking this process off-chain, substantial latency and privacy improvements can occur.”

Decred (DCR) describes itself as “digital currency for the people,” completely independent, community funded and community owned. The project wants to build an open and progressive cryptocurrency with a system of community-based governance integrated into its blockchain,  including a hybrid consensus system to ensure that no group can control the flow of transactions or make changes to the currency without the input of the community.

“Decred is Bitcoin as it should have been,” noted crypto-investor Jon Creasy. “Bitcoin would be of the people, for the people. As great an idea as this was, however, Bitcoin soon became controlled by an ‘oligarchy,’ so to speak.”

It’s important to note that some countries, such as China, are attacking cryptocurrency exchanges as the weakest links in the crypto ecosystem. The Decred move shows that, at least for crypto-to-crypto trading (for example, exchanging bitcoin for litecoin), it’s perfectly possible to operate without exchanges. However, it doesn’t solve the problem of crypto-to-fiat and fiat-to-crypto trading, which is arguably of top concern for cryptocurrency users.


Posted: 9/21/2017 12:35:31 AM Edited: 9/21/2017 12:36:50 AM
Gender: Unknown
Country: Unknown
Threads: 105, Posts: 779

Decred v1.1.0 “Thunderstruck” has been released (2017-09-23)



Decred v1.1.0 “Thunderstruck” — Development Dispatch 26

IMPORTANT: v1.1.0 "Thunderstruck" has a new vote agenda. Please upgrade as soon as possible to vote!

This development dispatch covers work completed since the Decred v1.0.7 release on August 18th, 2017.

Here are direct links to the Paymetheus (Windows) GUI wallet installers:

Decrediton (OSX, Linux) GUI wallet installers:

dcrinstall cross-platform text-based CLI installers:

All the various binaries except for dcrinstall:

NOTE: All Windows binaries only support Windows 7 and newer.

Instructions on how to verify the release binaries using GPG can be found here.


This release of dcrd primarily introduces a new consensus vote agenda which allows the stakeholders to decide whether or not to activate the features needed for providing full support for Lightning Network. For those unfamiliar with the voting process in Decred, this means that all code in order to support these features is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.

The following Decred Change Proposals (DCPs) describe the proposed changes in detail:

  • DCP0002
  • DCP0003 (This documentation is not complete yet. It will be available soon after release and before the vote begins.)

It is important for everyone to upgrade their software to this latest release even if you don’t intend to vote in favor of the agenda.

Notable Changes

Lightning Network Features Vote

In order to fully support many of the benefits that the Lightning Network will bring, there are some primitives that involve changes to the current consensus that need to be enabled. A new vote with the id lnfeatures is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or stake pool’s website.

Transaction Finality Policy

The standard policy for transaction relay has been changed to use the median time of the past several blocks instead of the current network adjusted time when examining lock times to determine if a transaction is final. This provides a more deterministic check across all peers and prevents the possibility of miners attempting to game the timestamps in order to include more transactions.

Consensus enforcement of this change relies on the result of the aforementioned lnfeatures vote.

Relative Time Locks Policy

The standard policy for transaction relay has been modified to enforce relative lock times for version 2 transactions via their sequence numbers and a new OP_CHECKSEQUENCEVERIFY opcode.

Consensus enforcement of this change relies on the result of the aforementioned lnfeatures vote.

OP_SHA256 Opcode

In order to better support cross-chain interoperability, a new opcode to compute the SHA-256 hash is being proposed. Since this opcode is implemented as a hard fork, it will not be available for use in scripts unless the aforementioned lnfeatures vote passes.


This release focuses on adding voting agendas for the hard forks described in DCP0002 and DCP0003. It also comes with the normal set of bug fixes and improvements.

New features

  • A new gRPC method WalletService.CreateSignature has been added to create a raw transaction input signature. This is useful for clients that need to include signatures in non-standard scripts without resorting to dumping a private key and signing in the client.
  • The gRPC WalletService.Balance result has been updated to include the unconfirmed balance. This unconfirmed balance has the same semantics as the unconfirmed field from the getbalance JSON-RPC result.

Other improvements

  • The help text for the addticket JSON-RPC method has been updated to reflect that fact that manually added tickets are not reported in the statistics returned by the getstakeinfo method.
  • Added support for Go 1.9. Release binaries are now created using this Go version.
  • The sample config has been updated for the current configuration defaults. This sample config had not been updated in the past when default config options were changed.

Bug fixes

  • Revocations can now be created which double spend an unmined vote, as long as the vote is not voting on the most recent block. This allows revocations to be created for votes that were made but not included in the block by miners.
  • Tickets manually added through the addticket JSON-RPC method are now included in the gettickets results. This is required for correct stakepool functionality.
  • An off-by-one was fixed when logging the number of watched addresses at wallet startup.
  • A divide-by-zero error has been fixed when attempting to use the integrated ticket buyer starting from the genesis block on simnet.


This release Decrediton is significant for a few newly added features and improvements. With the help of jrick, we are now able to control child processes properly in Windows and are now able to add Windows support. The Windows version of Decrediton will be released in the next few days, due to an issue with the build process.

The entire startup process has been refined to help users understand what is happening behind the scenes. Now it should be clear to users when the blockchain is downloading and what the consequences are for skipping initial

We have also completed work on the initial phases of the React/Redux refactor. All inline styles have been replaced with Less styling and all components have been broken up into logic and presentation portions. The next step will be to audit and refactor the Redux state and ensure that everything is immutable and recording proper state.

The following release will include a completely redesigned UX for staking. We hope that this will make staking more approachable to new users. We will also be adding complete ticket status information and basic graphs for users to visualize their accumulated returns from staking.

New Features

  • An “About” window now shows current Decrediton version, plus versions of packaged dcrd and dcrwallet binaries. This should help debug users’ issues going forward.
  • New startup procedure. We now wait for dcrd’s RPC connection to be available and subsequently check block count. We can now show users an estimated time for full blockchain download. This done by using a best guess according to 5 minutes per block and when the chain launched. We plan on using more intelligent methods of checking current block height in the future.
  • Send all. Users can now construct transactions that will completely drain an account. Simply select the account you would like to send from, click “Send All” then enter you destination address. You will then be shown the amount to be sent and the estimated fee. Click send and enter your private passphrase to complete the transaction.
  • Show rescan progress in sidebar. This should help users avoid confusion after linking ApiKeys or importing scripts.
  • Allow for basic resizing of the application window. We are currently designing fully implemented media size break points. But in the meantime this fix should allow users with low PPI screens to see the entire application view.

Bug fixes

  • Clear stakepool configurations when creating a new wallet. Otherwise, users could get into unintended situations with stakepool settings from one wallet being attempted on another. Other checks were still in place to avoid major issues, but this led to undesirable UX.
  • Show pending transactions of all types in the overview and the history page.
  • Fix erroneous reloads and form submission in get started pages.
  • Settings were being saved on field change instead of Save Setting submit.
  • When using testnet, use different background color in SideBar to accentuate that is is a different network.


This release is likely to be the last, or one of the last, Paymetheus releases. We have decided to unifiy efforts into development of our cross-platform GUI, Decrediton. We will continue to search for interested WPF/xaml developers that would like to continue development of this native Windows GUI. Users are encouraged to migrate to the Windows release of Decrediton by importing your Paymetheus seed. In the meantime, this release of Paymetheus contains the updates for voting on DCP0002 and DCP0003 and is intended as an interim release to smooth the migration process.


We would like to thank our contributors for their work this release: ay-pdavecghdhilldnlddgo1dfish, jcmincke, jolanjrickjpzmarcomatheusdpeterzen, and sndurkin.


Originally published at forum.decred.org on September 23, 2017.

Posted: 9/25/2017 11:18:57 AM Edited: 9/25/2017 11:19:56 AM