1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. jy-p

    jy-p Sr. Member

    Jan 2, 2016

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

    Here are direct links to the Paymetheus GUI wallet installers:
    decrediton cross-platform GUI wallet installers:
    dcrinstall cross-platform text-based CLI installers:
    all the various binaries except for dcrinstall:
    NOTE: All Windows binaries only support Windows 7 and newer.

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

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

    Marketing, Documentation and Development Contractors

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

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

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

    Substantial Design Update

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

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

    Hard Fork Voting Demo

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

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

    Major GUI Wallet Progress

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

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

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

    Public keys

    The file cmd/dcrinstall/pubkey.go contains the decred public key which is used to check the signed manifest in the release. You can compare the contents of this file to what you get from a keyserver to confirm that dcrinstaller is using the proper key.
  2. Dyrk

    Dyrk Sr. Member

    Jan 7, 2016
    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.
    Alexoz and Tivra like this.
  3. Tivra

    Tivra Member
    Advocate (BitcoinTalk)

    Dec 30, 2015
    I feel like I'm posting in a historic thread!
    Amazing work, devs and the team.
    Alexoz and Emilio Mann like this.
  4. Alexoz

    Alexoz Member

    Bravo!!! Ready for the first hard fork :D
    Emilio Mann and Tivra like this.
  5. LedgerNano

    LedgerNano New Member

    Jul 4, 2016
    amazing work! Let's fork :D
    Alexoz and Tivra like this.
  6. coin_artist

    coin_artist New Member

    Jul 21, 2016
    Visit https://faucet.decred.org/ to receive testnet coins! You'll need these to participate in the hard fork voting on testnet.
    Alexoz likes this.
  7. Emilio Mann

    Emilio Mann Full Member
    Advocate (Facebook)

    Jan 9, 2016
    Thank you @jy-p and all team!
    skydivebr and Alexoz like this.
  8. jinlei

    jinlei New Member
    Translator (中文)

    Jan 7, 2016
    great work!!!
  9. 418Sec

    418Sec Member
    Advocate (Twitter)

    Jan 3, 2016
    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! :)
  10. N3wb1e

    N3wb1e New Member

    Jun 12, 2016
    Good work!
  11. zero

    zero Full Member

    Jan 1, 2016
    #11 zero, Feb 14, 2017
    Last edited: Feb 14, 2017
    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.
    chappjc likes this.
  12. chappjc

    chappjc Full Member
    Developer Pool Operator (PoS)

    @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.
    zero and Tivra like this.
  13. jrick

    jrick Member

    Jan 4, 2016
    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.
    zero and Tivra like this.
  14. David

    David Sr. Member

    Jan 22, 2016
    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!!
    Tivra likes this.
  15. jcv

    jcv Full Member

    @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.
    zero likes this.
  16. zero

    zero Full Member

    Jan 1, 2016
    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= :



    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.
  17. drunkenmugsy

    drunkenmugsy Sr. Member
    Advocate (Reddit)

    Dec 28, 2015
    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
    dcrctl.exe --wallet purchaseticket "default" 40 1 Dcnzj252uU8... 10 DsnTxKKQSazRXsc... 5 106715
    dcrctl.exe --wallet purchaseticket "account" price confirms poolAddy #tixToBuy poolAddy poolCost% cancelAtTix#
    zero likes this.
  18. moo1337

    moo1337 Moderator

    Jul 25, 2016
  19. zero

    zero Full Member

    Jan 1, 2016
    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).
  20. zero

    zero Full Member

    Jan 1, 2016
    #20 zero, Feb 25, 2017
    Last edited: Feb 25, 2017
    @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:


    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.

Share This Page