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.
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
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
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
Paymetheus - Windows 64-bit | Windows 32-bit
gominer Windows 64-bit - CUDA | OpenCL | OpenCL+ADL
ccminer - Windows 64-bit |
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.
- RFP-1: Windows Wallet UI/UX Overhaul
- RFP-2: Web Wallet Ticket And Stake Pool Support
- RFP-3: Network Status Dashboard
- RFP-4: Refactor And Update Wiki Documentation
- RFP-5: Mining Protocol Development And Pool Integration
- RFP-6: Setup And Operate 10 Stake Pools
- RFP-7: Identity, Alignment, and Design
- RFP-8: Higher Level Language Compiling to Transaction Script
- RFP-9: Alternative GUI Implementation
- RFP-10: Wallet RPC Test Coverage #1
IRC: #decred on irc.freenode.net
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
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.
Decred 0.7.0 Release Update
The 0.7.0 release has proven to be pretty challenging due to the introduction of soft-forking. Good news is that we are the bottom of
the barrel and are finishing final verification for release. Even though we think that we'll be done tomorrow we do not want to release
this right before Christmas weekend. We are therefore going to drop 0.7.0 on Monday the 26th.
Happy holidays from your fearless Decred team.
Decred verson 0.7.0 Release
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:
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. 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)
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
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.
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.
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.
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 here in the forum thread.
- 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.
Here’s a little announcement for what's to come regarding Decred's design development.
Our goal was to create an engaging and recognisable identity and design
direction to represent Decred across different platforms and contexts.
We’ve worked out a common vision and a set of principles with Decred
core team to bring longevity, togetherness, and representation for it
both as a cryptocurrency and as a project in any environment.
The estimated launch for the new visual identity and design direction is February 2017.
What to expect:
- The new visual identity and design system
- New Decred main site
- New designs for the key platforms (docs, forum, social media, webwallet, decrediton, mainnet etc)
- Visual communication toolkit (graphical assets, icons, illustrations, typography, useful guides etc)
It is needed to make it easier to tell about Decred. For this we’ve
created the visual communication toolkit. Anyone who wishes to represent
Decred can use it. It contains a set of simple + practical tools and
guides for different contexts – e.g. for creating marketing materials,
information/communication design or application design.
The main site and key platforms received a design overhaul for a
consistent and professional representation of Decred. The wider goal is
the create international awareness and legitimacy. For new (and old)
users the goal is to help with the on-boarding process, building
understanding of Decred as well improving the general experience.
If anyone plans or is currently creating new graphical content, I
recommend not to use any pre-released, copied or re-drawn logos and
symbols you might have already seen. Instead use “Decred" logotype (without symbol) or “DCR"
in a simple, clean and bold textual form (e.g. typeface: Montserrat
Bold) until the appropriate files and the toolkit is released. This will
help avoid wrong first impressions and any possible confusion.