Updated Details Decred




  • Decred is an open and progressive cryptocurrency with a system of community-based governance integrated into its blockchain.

    The fusion of technology, community, and governance the Decred way means development is self-funding and remains sustainable.


    Technology


    Hybridized proof-of-work proof-of-stake consensus system to strike a balance between miners and voters and create a more robust notion of consensus Blake-256 hashing algorithm – not vulnerable to many of the numerous security issues facing Merkle-Damgård construction-based hashing algorithms such as SHA-256 secp256k1 signature scheme for ease of integration into existing software or Ed25519/secp256k1-Schnorr to take advantage of Schnorr signatures and their features Written entirely in Go using a modular, well-documented, and tested codebase for long-term maintainability



    Development

    Multi-stakeholder development ecosystem that welcomes and empowers participants who want to build new and improve on existing features Open and self-funded development via a block subsidy to ensure long-term development sustainability as project and network usage scale upward – Decred improves with use Any party can submit feature proposals and developers are paid for work to fulfill requirements – in full view of the community in a system designed to fight against ingroup-outgroup dynamics Main contributors are the developers responsible for btcsuite (est. early 2013 – present) – a suite of Bitcoin packages and tools, including btcd, a full node, mining capable, Bitcoin implementation


    Governance

    Layered form of transparent meritocratic governance that extends beyond proof-of-work and proof-of-stake mechanisms to bring forward and represent insider and outsider voices in the community Bottom-up decision-making through the Decred Assembly – an evolving and inclusive list of community members who make non-financial contributions to the project through their work and effort Project bound by the Decred Constitution on the core principles of finite issuance, privacy, security, fungibility, inclusivity, and progressive development of the technology that keeps these principles together


    Core Software:

    Installers

    Binaries

    Web Wallet


    GUI Wallets:

    Paymetheus - Windows 64-bit | Windows 32-bit

    Copay - Mac OS X | Linux 64-bit

    Supported Miners:

    gominer Windows 64-bit - CUDA | OpenCL | OpenCL+ADL

    gominer Linux 64-bit - CUDA | OpenCL | OpenCL+ADL


    Other Miners

    :

    ccminer - Windows 64-bit |

    Linux 64-bit

    Claymoresgminer


    Technical Features


    The features below are implemented in Decred and will be available in full at launch. For a deeper description, please consult the Decred Technical Brief.


    Novel hybridized proof-of-work/proof-of-stake (PoW/PoS) consensus system - A decentralized lottery is used to select PoS miners to vote on PoW blocks. The PoW and PoS subsidies account for 60% and 30% of each total block subsidy, respectively. This system is based on that of MC2, which is very similar to, but developed independently from, Proof-of-Activity (PoA) by Iddo Bentov, Charles Lee, Alex Mizrahi and Meni Rosenfeld.

    Cold staking and decentralized stake pooling - The ability to generate new coins without the risk of having your coins online when PoS mining. The PoS mining system has also been engineered with distributed, decentralized stake pooling in mind, so that even those with small amounts of stake can participate in network validation.

    Internal voting system for the addition of new features and hard or soft fork selection - Both PoW and PoS miners can vote for features and issues through bit flags, providing a sensible mechanism for resolving disputes about the features of the blockchain.

    Immutable transaction hashes ("transaction IDs") by separating transaction signatures from the rest of the transaction data - A permanent fix for transaction hash malleability has been implemented that prevents mutability of the transaction hash by separating it from its input signatures. This allows more efficient SPV validation. Fraud proofs have also been added.

    Elliptic curve cryptography over secp256k1 with optional Curve25519 support - The Bitcoin scripting system has been modified to allow for simple, drop-in addition of new elliptical curve digital signature algorithms.

    Schnorr signatures with threshold n-of-n support - In addition to supporting Schnorr signatures, groups of signers can now jointly sign transactions off-chain in constant size signatures, ensuring higher privacy and less blockchain bloat.

    Script enhancements and new OP codes - New OP codes have been added to the existing Bitcoin scripting engine, and extensions for the plug-in use of future scripting engines have been added.

    PoW mining using BLAKE256 hash algorithm - Inspired by Bernstein's Chacha stream cipher, SHA3 finalist BLAKE256 offers speed as well as high security.

    Compatibility with Bitcoin transaction scripting system - Decred's scripting system has been derived from Bitcoin's with care in ensuring that all future updates to the Bitcoin transaction script will be easily extensible to Decred. Further, any newly created functionalities will also be devised with backwards compatibility with Bitcoin in mind.

    Modularized, easy-to-use Golang btcsuite codebase - Thanks the to the codebase inherited from btcsuite, adding new features to the daemon or wallet will be facile. Decred will episodically sync updates from btcsuite, so that it benefits from the latest developments in Bitcoin.

    Hierarchical deterministic (HD) wallets - Wallets use a seed to deterministically generate addresses, so your wallet can be restored from a single BIP0032 seed.

    Transaction expiration - Transactions have a new expiration field to prevent inclusion into the blockchain after a certain height.

    Patches for intrinsic Bitcoin bugs - Extra push for multisignature scripts has been removed, SIGHASH_SINGLE behavior has been corrected.

    Approximately 21 million coins - Exponential decay in subsidy or the number of coins generated per year.

    Self-funded development via block subsidy - In order to have an ongoing source of funding for development work, a consensus rule has been added to allocate 10% of each block subsidy to a development organization. This entity is transparent and responsible for funding development work performed by current and new developers so that the project remains sustainable without a funding dependence on outside forces in the future. Decred therefore improves with growth in a sustainable way and is accountable only to its users.


    Project Governance and Development

    In addition to the technical features that make up the technology, Decred as a project introduces several development and governance features and proposals to ensure and steer long-term growth. We encourage participants to discuss these topics earnestly, as we want to ensure the system of development and governance is built on a solid foundation.

    • A multi-stakeholder development ecosystem that welcomes and empowers participants who want to build new functionality and improve on existing features.
    • Any party can submit feature proposals and developers are paid for work to fulfill requirements. This is done in full view of the community in a system designed to fight against ingroup-outgroup dynamics.
    • The initial contributors are the developers responsible for btcsuite (est. early 2013 - present).
    • A proposal for a layered form of transparent meritocratic governance that extends beyond proof-of-work and proof-of-stake mechanisms to bring forward and represent insider and outsider voices in the community.
    • A proposal for bottom-up decision-making through the Decred Assembly, an evolving and inclusive list of community members who make non-financial contributions to the project through their work and effort.
    • The project is bound by the Decred Constitution on the core principles of finite issuance, privacy, security, fungibility, inclusivity, and progressive development of the technology that keeps these principles together.



    Resources

    Documentation: https://docs.decred.org


    Getting Started:


    Windows

    LinuxOS X

    Web


    Mining:


    Proof-of-stake (PoS)

    Proof-of-work (PoW)


    FAQ

    Advanced
    Research

    Block Explorers:


    Testnet

    Mainnet


    User Projects


    Android Decred Widgets

    Pydecred

    Decred J Wallet -- Java Gui Wallet

    PoS Miner Portal

    Dcrstats.com - Decred Network Dashboard

    Decred Wallet GUI

    D3c.red - Another Decred Dashboard

    Bitstream For Ztex 1.15y

    Bash Shell Script To View Quick Stats On Balance And Tickets

    Decred Gateway

    Decred Monitor And Data Collector - Dcrspy

    Requests for Proposals (RFPs) source


    Additional Information

    Website: https://decred.org
    Forum: https://forum.decred.org
    Wiki: https://wiki.decred.org
    GitHub: https://github.com/decred
    Reddit: https://reddit.com/r/decred
    Twitter: https://twitter.com/decredproject

    IRC: #decred on irc.freenode.net



    Exchanges:







  • Upcoming Emergency Fix.

    Unfortunately, we are currently in a hard-fork situation due to 0.6.0release. We are working on an emergency fix which should land soon. We'll post upgrade instruction and binaries as soon a humanly possible.

    The potential fix is at: https://github.com/decred/dcrd/pull/490

    More soon.



  • 0.6.0 Forking Bug Post-mortem


    A 0.6.0 forking bug was triggered during the afternoon of Friday,November 25th, 2016, at block 84120, which was mined at appoximately 14:44 CST. This bug only affected nodes running version 0.6.0 forreasons that will be explained below. While, technically speaking, this was indeed a forking bug in version 0.6.0, there were only 1 or 2 blocks mined on the forked chain, so there were not 2 chains of
    comparable length running in parallel. Rather, the 0.6.0 nodes effectively stopped since their chain had stalled. Roughly 7 hours later, at block 84157, a 0.6.1 patch release was pushed that fixed this
    issue. We also pulled the 0.6.0 release from GitHub to prevent anyone from inadvertently downloading it in the future. Running any version besides 0.6.0 will get your node past block 84120, but you may need to
    restart dcrd a couple times to get the chain to sync.
    This bug involved a number of issues that worked in concert to jam the chain for 0.6.0 nodes. Those familiar with software development are
    welcome to have a look at the commit that fixes the problem.




    Since most users are not developers, this commit requires some


    explanation. There are a few key points to take away from this commit:The dcrd code from the initial February 8th release contained a bug where the function isMajorityVersion was called using an incorrect variable. When iterating to determine whether a new majority version had been triggered, the iteration was only occurring over the last CurrentBlockVersion blocks, instead of the last BlockRejectNumRequired blocks. Since CurrentBlockVersion was set to 2 for the 0.6.0 release, this meant that only having 2 version 2 blocks in a row triggered the requirement that all blocks must be version 2 from that point forward. The expected value for BlockRejectNumRequired is 950 on mainnet, so this led to premature rejection of blocks that were version 1. The commit fixes the incorrect parameters.It is clear thateither the majority of the PoW miners and/or the PoS miners were not running version 0.6.0, which led to the 0.6.0 nodes jamming. Based on the blocks that followed 84118-84120 having v1 instead of v2, it indicates that either (A) the majority of PoW was running v1 nodes and the majority of PoS was running v2 nodes or (B) the majority of PoS was running v2 nodes and the majority of PoS was running v1 nodes. Once the majority of PoW and PoS miners were running non-0.6.0 nodes, the chain started running smoothly again.CurrentBlockVersion really has no business being a parameter for the whole chain since it will vary as the chain advances. CurrentBlockVersion should not be included in the consensus rules. The commit removes this variable from the list of chain-wide parameters.CurrentBlockVersion should not have been changed to 2 for version 0.6.0, and it should have been tested on testnet and/or simnet before pushing it to mainnet, to verify it had no adverse effects. We were already planning to do this more thorough testing of the upcoming softfork in 0.7.0 here, here and here.Additional full-block tests need to be added to dcrd to ensure version changes do not fork or otherwise halt the chain. These tests were missed since we did not expect version enforcement to occur until the soft fork enforcement is added in the coming 0.7.0 release.Creating an easy-to-access fix for this bug required cutting anemergency patch release, version 0.6.1, on a Friday evening, and thistook us a few hours to complete. We take this forking bug as a reminder that both test coverage and behavioral testing are key to ensuring the stability of the Decred chain, especially now that we are blazing a newtrail towards upgrading consensus code on an ongoing basis.Feel free to ask any further questions you have on this topic in this thread.