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: Paymetheus v0.8.0 64-bit Paymetheus v0.8.0 32-bit decrediton cross-platform GUI wallet installers: decrediton v0.8.0 Linux 64-bit decrediton v0.8.0 OS X 64-bit dcrinstall cross-platform text-based CLI installers: https://github.com/decred/decred-release/releases/tag/v0.8.0 all the various binaries except for dcrinstall: https://github.com/decred/decred-binaries/releases/tag/v0.8.0 NOTE: All Windows binaries only support Windows 7 and newer. A lot has happened in the past several weeks since the 0.7.0 release of Decred. On the valuation front, the exchange rate has gone up substantially from a low of approximately USD 0.43 on December 28th to an all-time-high of USD 3.31 on February 5th, which has since settled around USD 2.50. The number of downloads of binaries from GitHub for the 0.7.0 release has gone up by a factor of 5 or more, and we have a substantially larger number of users in Slack and other chat channels. This substantial improvement in valuation, exposure and community engagement is due mainly to our recent work with several marketing contractors via the dev org, DHG, which I will say more about below. Beyond matters related to Decred's valuation, there has been substantial progress on several of our software projects and with their documentation. The bulk of the code needed to enable hard fork voting has been completed, and it will be demonstrated live on testnet over the next few weeks, via a corresponding website that shows its progress. A substantial design overhaul has been completed during the past several months, which includes a new logo and changes to every project website. decrediton, the cross platform GUI, has made a huge amount of progress, going from an alpha project to a solid beta in a single release. Paymetheus, the native Windows wallet, now uses the new stakepool API integration to simplify setting up ticket buying with a stakepool. Several additions and updates have been made to the Decred documentation site by documentation contractors. More detailed descriptions of our progress can be found below. Marketing, Documentation and Development Contractors Per the recent 2017 Decred Roadmap, a deliverables-driven RFP process did not end up working out very well, so we have since changed our RFP process to be need-driven by domain. The dev org, DHG, has contracted 5 people to do marketing, 2 to do documentation and 3 to do development work. So far, this arrangement is working out very well and has led to substantial progress on the marketing and documentation fronts. The marketing contractors have met with considerable success in increasing awareness, engagement and generally creating demand for decred. The puzzles created by @coin_artist have been particularly effective at drawing new users to our Slack channels and creating a general buzz about Decred. The efforts of @Daniel, @Emilio Mann, @Tivra and @Dyrk have served to grow our community, engage new users, create additional demand, support regional markets and broaden our social media support. Overall, this marketing work has been very successful to date. The documentation and development contractors have started doing work more recently, so they haven't had as much time as the marketing contractors to get their deliverables flowing. @gratefulcheddar and @Shadowlance have been pushing out a lot of new and updated documentation over the past few weeks, and their output should become much more apparent over the next few months as they shore up the Decred documentation. @karamble has pushed out a lot of web development work in the past couple weeks, which has made an otherwise monolithic release much more manageable. @raedah has submitted several pull requests that improve dcrwallet's ticketbuyer, which should lead to improvements in the fee market for tickets. We expect the contributions from our documentation and development contractors to become more apparent in the coming months. Substantial Design Update A design overhaul of Decred was initiated in RFP-7 several months ago with @linnutee, and it is being brought to completion with the 0.8.0 release. The work includes a new logo, design updates for every project website and a branding package for other Decred-related projects to use. As you can imagine, updating every website the project maintains is a pretty daunting task, so beyond @linnutee and sander doing all the design and coding, we had @karamble integrate and audit their work, and @Shadowlance contributed text copy in several places. For those who are interested in the details of this work, I recommend you give @linnutee's recent Medium post a read. Hard Fork Voting Demo While it's certainly less tangible than a surge in the exchange rate, the core of Decred is based around decentralization as a process, and the first major step in that process, hard fork voting, has been prepared for a demo on testnet. Stakeholders will soon have the ability to vote on defined issues in dcrwallet, and this will allow Decred to episodically hard fork based on how its stakeholders vote. If 75% or more of the stakeholders vote “yes” for a given issue during a voting period, it will go into effect approximately 4 weeks later (on mainnet), and this includes “hard fork” consensus changes. Getting this code ready has been particularly challenging since it is all consensus-related code, which is notoriously unforgiving when it comes to bugs. The testnet demo has an accompanying webpage that allows users to watch each step in the voting process occur. We chose to have a single issue for the demo, to increase the block size from 1 MiB to 1.25 MB, and we felt this was appropriate since the block size has been so contentious for Bitcoin. There are 3 stages to hard fork voting, which is reflected on the demo website, and this process draws from some parts of the BIP0009 soft fork process from Bitcoin. First, Proof-of-Work miners must update their dcrds to the latest release until a threshold percentage, 75% in the case of testnet, of blocks in a rolling window show the new block version in their header. Second, Proof-of-Stake miners, i.e. stakeholders, must update their voting wallets to the latest release of dcrwallet until a threshold percentage, 75% for testnet, of votes in blocks in a fixed window show the new vote version. At the end of the first interval with 75% or greater support for the new vote version, the stake version is incremented to the new version and a voting period begins. Once a voting period comes to an end, any issues that receive 75% or greater 'yes' votes are considered complete and will become active after a lock-in period. Issues that receive 75% or greater 'no' votes are considered dead and will not be voted on further. If an issue does not receive a 75% or greater vote either direction, the issue remains up for voting in future voting periods until an expiration time is reached. The process of upgrading PoW miners, PoS miners and voting will occur on an ongoing episodic basis and allow Decred's consensus code to evolve over time, according to the will of its stakeholders. We estimate that it will take 3-6 weeks for the testnet demo to have the block size increase voted in and for the hard fork to occur, so users can stop by and check the progress on the webpage. Major GUI Wallet Progress Until this release, only Windows users had the option of running a self-contained GUI wallet with Paymetheus, so we are pleased to announce that decrediton, a cross platform GUI wallet, is ready for use on Linux and OS X. decrediton now supports all the basic wallet functions and delivers most of what users would expect a GUI wallet: it is simple to install, has a graphical setup wizard, can restore from existing wallet seeds, and can send and receive payments. Considering that the 0.7.0 release of decrediton was in a very much “alpha” state, this release constitutes a huge leap forwards in terms of improved user experience. Beyond the decrediton progress, Paymetheus has added support for a new stake pool integration API, which simplifies the process of using a stake pool with Paymetheus. Once a user has registered an account at a stake pool, they can copy an API key from their stake pool login into Paymetheus, and then Paymetheus handles the rest of the stake pool setup. Prior to adding this API to stake pools, the user would have to generate a pubkey, copy and paste it to the stakepool, hit a button, and then copy and paste the multisig address back into Paymetheus. We had originally wanted to make even signup for a stake pool possible via this API, however, this created an obvious Denial-of-Service vector and had to be removed. The new process for using a stake pool is much less error prone and avoids confusion on part of users, so it is a notable improvement. By the next release, both Paymetheus and decrediton will support automatic ticket buying and have an interface for users to set their voting preferences. Between this release and the next, we will make minor releases that include these new features in the GUI wallets, so that users can test them and give us feedback. We will announce these minor releases and provide updated binaries to make it easy for everyone to test out the new features as they are added. Public keys The file cmd/dcrinstall/pubkey.go contains the decred public key which is used to check the signed manifest in the release. You can compare the contents of this file to what you get from a keyserver to confirm that dcrinstaller is using the proper key.
And here it goes. Finally, we have a hardfork voting I'm already fully loaded with testnet tickets, so feel free to contact me or official devs, if you need some testnet coins. Thanks devs for the awesome job.
Visit https://faucet.decred.org/ to receive testnet coins! You'll need these to participate in the hard fork voting on testnet.
Great Job decred team! The much awaited update is finally here! Also, I am happy to announce, DCRstakes.com is updated and ready for action. Thanks for the support!
Another great release! A big thanks to all the Decred developers! @jy-p @davecgh @jcv I'll update soon from v0.7.0 but since everything is working totally stable for now, I have some answers for any possible changes: 1) Does any of these commands for CLI changed with v0.8.0? : dcrwallet --username="dcrwallet_username" --password="dcrwallet_password" --walletpass="public_passphrase" --dcrdusername="dcrd_username" --dcrdpassword="dcrd_password" --enablestakemining --pooladdress=poolfeesaddress --poolfees=5 --ticketaddress=P2SH_Pool_Address --balancetomaintain=x.x --ticketmaxprice=x.x --ticketbuyfreq=x dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet purchaseticket "default" xx x ticketaddress x pooladdress 5 dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet listtransactions dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet getbalance dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet getbalance "default" 0 all dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet getbalance "*" 0 all dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet walletpassphrase "private_passphrase" xXxX dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet setticketfee x.xx dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet settxfee x.xx dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet getstakeinfo And if any of them will not be working anymore what it's alternative with v0.8.0? 2) Is there a command to revoke - cancel tickets bought that I predict they won't get mined before the end of 144 blocks period (because of fees)? 3) In case of re-seed do I need to re-import the script from stake pool to get the correct stats with -getstakeinfo? 4) Are there any other major changes for CLI use for buying tickets for stake pools or in general? 5) GUI wallets are great news for newcomers but I think I'll stay with old good CLI for now. Anyway I want to ask if Paymetheus is stand-alone now and if it starts syncing drcd in background? Or I'll need to use it just as dcrwallet alternative after drcd completely syncs the blockchain? 6) Considering hard fork voting which is now on testnet will it be "spam-proof", meaning that if someone might create multiple wallets just to vote more times (I know that I get this wrong and that everything will work fine but honestly I feel I should ask about it). OK these are many questions but I hope I'll get some answers before updating.
@zero The getbalance commands have changed slightly. The result is a more complex JSON structure, and the input no longer has the last argument, I think. About (3), the redeem script question, the scripts get automatically imported on rescan I have found. But I don't know if this is documented anywhere. About Paymetheus, it has a standalone option that is supposed to use an already-running dcrd. About vote spamming, it's not about number of wallets but rather number of tickets.
Hi all, we just made a patch release for Paymetheus. Any Paymetheus users who use stakepools **must** update. It fixes bugs regarding both manual and automatic stakepool ticket purchasing. See https://github.com/decred/decred-binaries/releases/tag/v0.8.1 for the release notes, installer links, and digital signatures.
What a journey this has been! To see where we started a year ago - a small community using the most basic CLI tools to a much larger global user base with fully functional cross-platform GUIs - is phenomenal. DGH and all the contractors - keep up the great work!!
@zero the main cmd line change is that the standalone dcrticketbuyer program is no longer provided and those functions have been merged into dcrwallet where they can be improved more easily.
Thanks for replying. I'll see how hard fork voting will go. Depending on number of tickets is safer, but even in this way big stakers can control the whole voting system - decision making. Anyway we'll see how this will go. Good to know, I'll check the list of commands available to figure out some things. I haven't ever used dcrticketbuyer, but if I am not wrong with dcrticketbuyer it was possible to revoke some of the ticket that bought and weren't mined before the ticket price period of 144 blocks, so is there a way to do that with dcrctl? So starting dcrwallet for auto-buying tickets for a stake pool is the same? And I've found there was an issue with --ticketbuyfreq= : https://github.com/decred/dcrwallet/issues/377 https://github.com/decred/dcrwallet/pull/517 Should I start dcrwallet with ticketbuyer.maxperblock instead or ticketbuyfreq flag is still supported? Anyway thanks for replying. I guess I'll have no problem.
I think what you want can be done by simply adding and expire block height to the end of your purchase command. This is what I use to purchase tickets in a stakepool. In this case I bought tickets in block 106695 and set them to expire if not mined in ticket 106715 Code: dcrctl.exe --wallet purchaseticket "default" 40 1 Dcnzj252uU8... 10 DsnTxKKQSazRXsc... 5 106715 dcrctl.exe --wallet purchaseticket "account" price confirms poolAddy #tixToBuy poolAddy poolCost% cancelAtTix#
For the people playing with the hard fork bits please check out this patch release: https://forum.decred.org/threads/0-8-2-decred-patch-release-for-testnet-only.5114/ Sorry for the cross post but I want to make sure that people are aware that there is an update. Patch is only relevant for hard fork on testnet so mainnet users do no need to be alarmed.
I've finally updated, everything seems to work. I understand why getbalance returns are changed with v0.8.0 since many users were confused with balances, but is there a getbalance "*" 0 all alternative? I'd like a command to get all accounts totals ("default""total" + "imported""total") without having to do this addition all the time. I didn't know I can use a cancelAtTix# value when I manually buy tickets, I mostly start dcrwallet for auto-buying tickets but I think that will do the job. Thank you. I guess I'll try this when ticket price will go back to normal (somewhere around 40).
@jcv Today I've used v0.8.0 to buy some tickets for stake pool and I've decided to move to the new ticketbuyer (starting dcrwallet with --enableticketbuyer and --enablevoting flags) since the old ticketbuyer (--enablestakemining) is deprecated. Everything is working fine with the new ticketbuyer but I'd like to ask if there is a way to change these values after I start dcrwallet: --ticketbuyer.maxfee=x --ticketbuyer.minfee=x --ticketbuyer.maxperblock=x --ticketbuyer.expirydelta=x --ticketbuyer.maxpriceabsolute=x --ticketbuyer.balancetomaintainabsolute=x --ticketbuyer.balancetomaintainrelative=x I've checked on dcrctl -l and I didn't find anything (like setticketbuyer.maxfee, setticketbuyer.maxpriceabsolute, etc). Do I have to stop dcrwallet and restart it with the new values every time I'll might want to make changes? And something else, I don't know if I missed something but when a ticket is bought (not mined - waiting to be mined or not) there is no representation on --wallet getbalance of the DCR spent to buy this ticket (ticket price + fees) until this ticket gets mined (and this value gets added in locked on tickets) or not mined (and this value returns back to spendable). I know this is not a real problem but it might confuse some users.