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 ![0_1482818756404_dd0.7.jpg](https://i.imgur.com/9sA489T.jpg) 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: [Paymetheus v0.7.0 64-bit](https://github.com/decred/decred-binaries/releases/download/v0.7.0/decred_0.7.0-beta_x64.msi) [Paymetheus v0.7.0 32-bit](https://github.com/decred/decred-binaries/releases/download/v0.7.0/decred_0.7.0-beta_x86.msi) 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. dcrrpcclient 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 dcrwallet 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 dcrd 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 dcrticketbuyer Bump for v0.6.1 (PR#77) Remove -v from go test. (PR#80) Bump for v0.7.0 (PR#81) Credits: @jcv decrediton 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. Important 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.
The v0.8.0 update has been delayed until 2/10/2017. To make up for it, here is a sneak peak of something our developers are putting together for the community to monitor the live demonstration:
Decred V 0.8.0 Release Update
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 @karambleintegrate 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.
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.
Decred (DCR) A New Ticket Price Algorithm
The 1.0.0 release of Decred will include the Decred Change Proposal, DCP-0001, the replacement of the existing stake difficulty, i.e. ticket price, algorithm as the first hard fork voting issue on mainnet. This is a major change and is being proposed to address the various issues that have come up with the stake difficulty (“sdiff” for short) since launch in February 2016. Decred launched with a sdiff algorithm that accomplished its basic design goal, which was to keep the ticket pool near its target size, but we have come to recognize several shortcomings and problems with the existing algorithm that were not apparent until it went into production use. The main problem is that a single interval where all the tickets are purchased leads to a persistent resonant mode, where very limited price exploration occurs, prices swing wildly and stakeholders compete on ticket fees. Replacing the existing sdiff algorithm with a new algorithm will lead to less wild variation in the ticket price and avoid the various problems associated with the existing algorithm. The properties of an ideal sdiff algorithm are related to:
- pool size stability
- price exploration
- relaxation time
- steady state behavior
which are explained in detail below. Currently, there are a few proposed sdiff algorithms from project developers and participants (raedah, animedow, and others) that we will be evaluating using a simulation harness developed by Dave Collins, dcrstakesim.
What is the purpose of the sdiff algorithm?
To understand an ideal sdiff algorithm, we must first understand the current sdiff algorithm. In order to keep PoS subsidy returns stable over time, Decred must maintain a stable ticket pool size, so we set the target size as 40,960 tickets. If the ticket pool size grows too large or too small, it can substantially alter the social contract between stakeholders and the network, disrupting the predictable nature of average time to vote a ticket, percentage of tickets that expire, and the rate of return. To maintain a target ticket pool size, the price of tickets must increase as the pool size goes up and decrease as the pool size goes down, to incentivize keeping the pool size near its target. Since users must observe the ticket price, choose to purchase and potentially wait to have their tickets mined, the ticket price must adjust on a interval basis. In what follows, further discussion of the sdiff interval size will be avoided and it is only mentioned here since it is a constraint imposed as a result of the ticket purchasing process.
The current sdiff algorithm
The current sdiff algorithm takes the historical values of pool size at the end of each interval and the number of tickets purchased in each interval for the last 20 sdiff intervals and the prior interval’s sdiff as inputs. The formula for the sdiff at interval N can be expressed ascurrent sdiff algorithm
where A is a function of the pool size of the last 20 intervals, B is a function of ticket purchases of the last 20 intervals, and sdiff_N-1 is the previous interval’s sdiff. The function A scales roughly linearly with the pool size, so as the pool size grows, A does as well. The function B oscillates up and down based on ticket purchase history, where a full interval of ticket purchases sends B as high as 4, and an empty interval can send it as low as 0.25. Both functions A and B use an exponential moving average (“EMA”) over the last 20 intervals, meaning their values are “smoothed” relative to the past 10 days of ticket purchasing and pool size history.
The current sdiff satisfies the dead minimum requirements of a sdiff algorithm: it maintains a relatively stable ticket pool size, the price goes up when the pool size grows, the price goes down when the pool size shrinks, and the price is intervaled. The ticket pool size has drifted as high as 45,034, but has more recently drifted downwards to the 41-42K range. When there is a full or nearly full interval of tickets, the ticket price jumps for 2 or 3 intervals, discouraging buying during those intervals, often to the point where these intervals are completely empty. Unfortunately, there are several problems that have emerged with the current sdiff algorithm after launch in February 2016.
Shortly after Decred’s launch we noticed that the ticket price had begun to oscillate with a period of either 3 or 4 intervals. 1 full ticket interval would lead to the price staying high for 2 or 3 intervals, where no tickets would be bought during those intervals, and then returning to a price that was close to that of the full ticket interval. This process has been going on for over a year at this point, and is an emergent resonant state that occurs due to the sdiff algorithm doing a poor job of price exploration. After 1 full interval occurs, the ticket price jumps up so much that it is outside the range of prices that people are willing to pay for tickets, and when the ticket price drops to a sustainable level, it is close to the previous full interval price. This resonant mode of the sdiff algorithm has led to fee wars during the low price intervals since the demand for tickets at a reasonable price is greater than the maximum supply of 2880 in the 1 full interval. Over time, the average price of a ticket has slowly increased, as seen in the graph of ticket price below.
If we look at the functional form of the sdiff algorithm, what is happening with the ticket price becomes much clearer. Recall that
where A is a function that varies slowly and increases with the pool size and B is a function that oscillates with every interval and varies between 0.25 and 4. Mainnet historical data indicates that ticket pool size grew to over 45K before dropping, which translates to the function A having a higher value, increasing the amplitude of oscillations that come from function B. As pool size increases, the swings in the ticket price increase, leading to even worse problems with price discovery.
An ideal sdiff algorithm
Based on our experience with the current sdiff algorithm, we have come to realize there are several properties of an ideal sdiff algorithm that require consideration when finding a replacement algorithm:
- pool size stability
- price exploration
- relaxation time
- steady state behavior
These properties are explained in more detail below.
Pool size stability
The current algorithm does a decent job of keeping the pool size stable, but we’ve seen the pool size driven over 45K in certain conditions, which is less than ideal. Instead of only increasing the amplitude of price oscillations when the pool size was large, an ideal sdiff would steadily increase as the pool size grew, keeping the pool size closer to its target size.
Since 1 full interval causes the current sdiff to jump by up to a factor of 4, it does a very poor job of exploring the range of ticket prices users are willing to pay. If the maximum change in ticket price were bounded to a range where users are willing to buy them, it would be more reasonable to bound the changes to be a maximum increase of roughly 20% per interval, e.g. 1 full interval leads to a 20% increase in the ticket price next interval. An ideal sdiff would stay in the range of ticket prices that users are actually willing to pay since empty intervals only communicate there is zero demand, whereas a thinly bought interval gives quantitative feedback on demand. Similarly, in order to explore the ticket prices after a full interval, the sdiff should adjust downwards slowly, giving users the opportunity to buy at several prices above the price of the last full interval. This will allow for gradual increases in demand for tickets to lead to gradually increasing prices.
The current sdiff algorithm requires doing a bunch of calculations that involve pool size and ticket purchase history from the last 20 intervals, then dividing by the previous interval’s sdiff. The algorithm is complex and should be substantially simplified, so everyone can understand it more easily. Currently, the sdiff algorithm is
and I propose that an ideal sdiff algorithm would have the formideal sdiff algorithm
with some function C. This means only the pool size from the prior 2 intervals is needed to perform the calculation, and it scales the prior interval’s sdiff by a linear factor.
When the current sdiff is driven by 1 full interval of tickets, it takes 2 or 3 empty intervals before it “relaxes” to its prior state, i.e. it takes 2 or 3 intervals for a perturbation to return to an equilibrium state. In order to prevent the possibility of driving the price with full intervals leading to a falling ticket pool size, we have the requirement that the relaxation time should be less than approximately 3 intervals. The particular scenario we’re trying to avoid here is 1 full interval (2880 tickets bought, 720 called for voting) followed by 3 or more empty intervals (0 tickets bought, 2160 or more called for voting). This places a constraint on the number of periods over which the ticket price must drop after a full interval.
Steady state behavior
Steady state ticket buying, i.e. 720 tickets per interval, with the current sdiff does not have the behavior one would hope for: maintaining a pool size over target should have an increasing price and a pool size under target should have a decreasing price. An ideal sdiff would have the property that when steady state ticket buying occurs, the price increases when the pool size is over target, and the price decreases when the pool size is under target. In terms of the proposed simplified form of the sdiff algorithm from above, this dictates that the function C should have 2 components, one a function of the delta between the last 2 pool sizes and the other a function of the delta between the last pool size and the target pool size.
Proposed replacement sdiff algorithms
A few alternative sdiff algorithms have recently been proposed by project developers and community members to date in a github issue for dcrd. The algorithms proposed so far include
track the percentage change in the pool size between the last 2 intervals and scale the ticket price according to that percentage, e.g. ticket pool goes up in size by at most 2160 on a full interval and down by at most 720 on an empty interval, so scale the ticket price by the change in ticket pool size divided by the ticket pool size, which bounds the interval-to-interval changes at 5.27% on the increase side and 1.75% on the decrease side (from raedah)
select a particular asymptotic function of the delta between the current pool size and the target pool size, which is approximately linear for small deltas and near exponential for larger deltas, and use the current average ticket price as a base when calculating a new ticket price (from animedow)
tally the total amount of coins currently locked for staking, then take a linear combination of the ratio of the locked coins to the target pool size and the ratio of the locked coins to the current pool size as the new ticket price (from coblee)
We will evaluate these algorithms and others that we receive from the community over the next 2 weeks, publish the results of the simulations and select what we consider to be the best choice. These simulations will be transparent, reproducible and all the assumptions will be laid out in detail at that time.
Evaluation via simulation
In order to select a new sdiff algorithm, Dave Collins has created a simulation harness, called dcrstakesim, which we will use to evaluate each algorithm. Dcrstakesim simulates each proposed sdiff algorithm on a fresh simulated mainnet chain, and it includes logic to mimic users buying tickets as a function of the yield at a given ticket price. Additionally, it caps the percentage of the coin supply being locked for tickets, to ensure it reflects to what we’ve seen to date. While the algorithms proposed thus far are a great start, we will be evaluating them according to the ideal sdiff criteria specified above, which likely means making additional modifications to what has already been proposed. If you’re keen to propose an algorithm, have a closer look at what’s already there or provide constructive criticism, join us on GitHubDecred Forum or our Slack chat.
by Jake Yocom-Piatt