This development dispatch covers work completed since the Decred v0.1.3 release from April 10th, 2016. Since then, developers have merged 89 pull requests of code into 8 software repositories. New repositories were created and populated for an automated smart ticket purchaser known as dcrticketbuyer and extensive Decred documentation known as dcrdocs (https://docs.decred.org). During this period, a total of 129 commits occurred in these repositories and represent modifications to the effect of 36,730 lines of code added to and 6,882 lines removed from the Decred codebase. A series of RFP milestones were achieved and paid for from the development subsidy. Milestones paid for include (See: Status and Expenditures): RFP-1: The proposed design is integrated into a single view (e.g. the Account Summary view) (bebd22a) RFP-1: The proposed design style is integrated into the entire application, including a stake ticket purchase view (56889f0) A number of stake pools have come online in geographically diverse locations to support the network, which means users are no longer required to solo stake mine and can instead use a dedicated pool managed by skilled operators. These are, in alphabetical order: https://dcr.stakeminer.com https://dcr.stakepool.net http://pool.d3c.red http://stakepool.eu https://stakepool.dcrstats.com Two new RFPs were opened for proposals and closed for review. RFP-7 will establish Decred's identity, align its different platforms according to that identity, and redesign its landing site. RFP-8 will bring a higher level language for Decred's transaction scripting system, which will enable users to create transaction scripts, such as smart contracts. Binaries: https://github.com/decred/decred-release/releases/tag/v0.1.4 dcrd Synced a large number of fixes, improvements, and optimizations from upstream through July (163-b0255e0, 164-a3ff9f1), August (166-1da2845, 172-bee3c25), September (174-885070a, 175-d5144c5, 177-2cc7e75, 178-28f5ce5, 180-8ff81ff), October (202-415ad8f, 205-85d85e8, 206-e8e81fe), and November (212-4bffbb1, 217-e955b1f, 218-a98085e, 219-ab38a2c, 220-0dd5db0) 2015 Very old votes are now rejected from the memory pool by default (168-ebade40) Votes are now checked by the tickets they spend rather than the vote hashes, which fixes a cached block template issue (169-33dc0c7) Adjusted the getblockheader result to reflect changes required by the upstream sync (170-d293c9b) Improved memory usage when the sighashall optimization is set in chaincfg/params.go (171-653e13d) Fixed a legacy address encoding issue (179-118f795) Improved test coverage (181-4e14b54, 210-c052ff9, 214-001ecad) Changed the order of service flags to ensure their human-readable representation and to allow for the output to be deterministically tested (182-9c238a8) Fixed an issue where searchrawtransactionsresult missed various components of transactions (183-ac0d8fb) Added a reverse order option to the searchrawtransactions RPC command (185-718f0f4) Improved garbage collection percentage (187-f1f1933) Integrated a valid ECDSA signature cache in order to mitigate a certain DoS attack and as a performance optimization (189-e310d1d) Added a checkpoint for block 24,480 (190-aac2928) Updated the getinfo RPC command to include errors in the result (191-577f33c) Corrected verifymessage hash generation (192-9798cde) Added a new --minrelaytxfee option to allow the user to specify the minimum transaction fee in DCR/KB in which the fee is considered a non-zero fee (194-096e77d) Majorly refactored peer code into its own package and introduced a number of fixes, improvements, and optimizations (197-756eff2) Improved heap sorting (199-c3d7ede) Moved non-mempool specific functions to a new file (203-29a04bc) Added an optional locktime parameter to createrawtransaction (204-1987376) Moved DNS seed to chaincfg (209-1cd79a4) Fixed various issues with the peer and server packages (211-a27dc48, 215-619de72) Reworked and improved efficiency of stake submission (216-3799575) Improved error handling (222-708b400) Updated configuration (193-0c883ff), documentation (201-40d778d), initial protocol versioning (195-cb9d07a), and versioning (221-f3e603a) Credits: @ay-p, bclermont, @ceejep, @chappjc, dan-da, @davecgh, @dhill, @Dirbaio, @jcv, @jolan, jongillham, @Javed Khan, @jrick, kargakis, lologarithm, justusranvier, roasbeef, runeaune, wallclockbuilder dcrwallet Improved block timestamping (240-e4ebb93) Disabled ticket purchase by default in preparation for dcrticketbuyer (244-4950977) Enabled stake pool mode for mainnet (245-61c3979) Added a guide that explains how to spend from a cold wallet while offline and added a utility called movefunds to sign offline transactions (252-7190018) Fixed an issue with fee calculation for revocations so that fees for revocations are now calculated on a per kilobyte basis. The wallet now also triggers winner and missed ticket notifications on start up, so that revocations for tickets that were missed while the wallet was offline will be triggered when the wallet is started (254-fa736fd) Updated documentation (243-222b7de), logging (246-c48265a), configuration (247-d5c9a96), and versioning (253-c9476fa) Credits: @ay-p, @ceejep, @jcv, @jrick, @raedah, @tpruvot dcrrpcclient Synced from upstream through August (20-06e2185), 2015 Fixed ticket fee info command handling (23-0e48ddc) Added an optional locktime parameter to createrawtransaction (24-7df7e90) Added a filteraddr parameter to searchrawtransactions (25-231790f) Updated documentation (21-51f8ef1) and RPC commands (22-3f0eb39) Credits: @ay-p, @ceejep, dan-da, @davecgh, @dhill, @jcv, @jrick, wallclockbuilder dcrutil Synced from upstream through July (10-b1f27b6), 2015 Updated documentation (11-85fac3a) Credits: @ay-p, @ceejep, @davecgh, wallclockbuilder dcrticketbuyer Added a new user interface that shows the number of tickets purchased, fee prices, ticket prices, and the number of tickets in mempool. A sample configuration file is also included (1-471c747) Credits: @ay-p, @ceejep, @jolan gominer Fixed an issue with shutting down the miner (4-b935bbd) Removed unused constants (5-6a7a59b) Added a tunable intensity parameter (6-6b8bb1f) Credits: @jcv, @jolan Paymetheus Synced with upstream (6-aabe292) Credits: @ay-p, @ceejep, @jrick Developer Notes General use instructions for dcrticketbuyer dcrticketbuyer helps solve many of the current issues affecting ticket purchase in Decred, such as stabilizing the stake difficulty and ensuring that tickets have adequate fees at low difficulties. It is intended to be a powerful, set-and-forget replacement for the default ticket purchasing code in dcrwallet that does not take into account things such as recently purchased ticket fees, the next estimated stake difficulty prices, and the number of tickets currently in mempool. It automatically provides an advantage to those purchasing tickets at lower stake difficulties by intelligently setting ticket fees and ticket expiry. Larger stake miners may use it to ensure smaller swings in the ticket price, which will enable all users to better purchase tickets at the average ticket price. An explanation of the features of dcrbuytickets is supplied in the sample configuration file distributed with the binary, or located here: https://github.com/decred/dcrticketbuyer/blob/master/ticketbuyer-example.conf Those who purchase small amounts of stake tickets will want to disable minpricescale and maxpricescale by commenting it out and setting a reasonable maxpriceabsolute. For persons with larger amounts of stake, it is recommended to have the price scaling features enabled. dcrticketbuyer requires the following: dcrticketbuyer binary. The webui/ folder included with the binaries to be located in the same directory as the binary from 1. dcrd and dcrwallet set up and running. dcrwallet will need to be unlocked and contain funds for ticket purchases. Information about how to build the tool can be found here: https://github.com/decred/dcrticketbuyer A thread for discussion of the tool can be found here: https://forum.decred.org/threads/dcrticketbuyer-new-tool-for-automatic-ticket-purchase.3548/ A sample configuration file has been provided. If you wish to use the tool on mainnet, you will need to change at minimum the following parameters in the sample file: Code: dcrduser, dcrdpass, dcrdserv, dcrdcert, dcrwuser, dcrwpass, dcrwserv, dcrwcert, testnet Comment out features you do not wish to enable by adding a hash tag (#) in front of them. Setup this file carefully if you are using coins on mainnet. To start dcrticketbuyer with a configuration file, execute: Code: dcrtickeybuyer -C ticketbuyer.conf If the HTTP monitoring server is available, you will be able to see a live chart feed of information about ticket purchasing that is updated every block. The default HTTP server port specified in the sample configuration is accessible in a browser at: http://localhost:7770
Last I heard the master branch was unusable. The next day, we have a release. No code freeze period. No alpha, no beta, no release_client. No way I am going to download this. Edit: Thank you for the explanation below of the QA being done.
Please note that v0.1.4 is marked unstable, in the same way v0.1.3 was marked unstable in the past. If you prefer stable, stay on v0.1.3 until v0.1.4 is marked stable.
<edited> master should only be used for devs and people that like to help out with dev testing. we stopped merging PRs for 0.1.4 roughly 2 days ago and have seen consistent uptime and performance on all nodes with release. but like _ingsoc said, just stay on 0.1.3 if you'd like. 0.1.4 has tons of optimizations and peer fixes for added stability. All of these have been thoroughly tested for months upstream in btcd.
As @ay-p pointed out, we picked a stopping point for 0.1.4 in each repo and tested that while commits where being merged into master. That can be seen if you look at dates of the PRs vs the date of the tagged commit.
Aye, that is helpful. I had not seen the tag. Good to know there is QA being done. Thank you and @ay-p for the follow up.
Upgraded binaries, so far so good. Have not tried the dcrticketbuyer yet, but looking forward to setting that up. Thank you.
The median fee source is currently broken. If you use it you will end up with a ticket fee from a random transaction. Otherwise, it is a wonderful tool. Thanks, @ceejep
First, thanks for the new release. Everyone appreciates the developers' hard work! I need to point out that more people are running on builds from master than C0 might think. Since the recent deluge of PRs to sync upstream, especially the peer package related ones, nodes have been dropping like flies. A number of VERY reliable (over the long term) nodes have been having poor short-term reliability. This is just a snapshot, and nodes bounce back, but they have been going up and down a lot lately. Prior to 0.1.2, I rarely saw hourly < monthly reliability for the top 20-30 nodes. It is very common now. The idea of a reasonably stable master was fairly well respected for a while. (Not that anyone ever said that master was supposed to be stable!) While I understand that this project is under active development -- heavy development at times -- perhaps there needs to be a little more communication to the people who decide to live on the edge. Many people do want to test and help with development, but it's less appealing when the risk is high. An announcement of large upcoming changes would have been helpful, for example. Perhaps I missed a thread though.
I agree it should have been brought up more that master may be unstable in the short term. Right now we're syncing all the infrastructure added to btcd over the last year, because it will be impossible to add the voting infrastructure and new OP codes without a higher performance database. As we learned from syncing wallet, syncs almost always introduce bugs. Many of the synced components are also partially incomplete, such as the signature cache. From now until that happens, which may be weeks, 0.1.3 should be considered the most stable releases and used in production. Still, we don't want to discourage running newer versions at all. Without feedback, it's impossible to know what might be wrong with them.
Too many new things. Congratulations to everyone involved with this release. @ceejep After updating to v0.1.4 from v0.1.3 can we leave dcrticketbuyer as optional and start dcrwallet for auto-buying tickets for a stake pool the same as on v0.1.3? Can we also use the same command for manual buying tickets as on v0.1.3? dcrticketbuyer seems very handy if it’s stable. I’d like to give it a try. Can somebody confirm that these theoretical settings for ticketbuyer.conf are valid (on Windows) for using dcrticketbuyer for auto-buying tickets for a stake pool: dcrduser=dcrd_username dcrdpass=dcrd_password dcrdserv=127.0.0.1:9109 dcrdcert=C:\Users\your_username\AppData\Local\Dcrd\ dcrwuser=dcrwallet_username dcrwpass=dcrwallet_password dcrwserv=127.0.0.1:9110 dcrwcert=C:\Users\your_username\AppData\Local\Dcrwallet\ httpsvrport=7770 httpuipath=webui/ testnet=false !Can we totally remove this for mainnet?! accountname=default maxperblock=2 maxinmempool=20 maxpriceabsolute=14.0 balancetomaintain=100.0 expirydelta=140 ticketaddress=ticket_address_from_pool pooladdress=pool_fee_address poolfees=5.00 !If the pool fee is 5%! #maxpricescale=2.0 !#disabled? Or better remove it if we don’t want it?! #minpricescale=0.7 !#disabled? Or better remove it if we don’t want it?! pricetarget=0.0 !0.0 = disabled? Or better remove it if we don’t want it?! maxfee=0.02 minfee=0.01 feesource=mean !median isn’t stable right now! feetargetscaling=1.01 txfee=0.01 !lower than 0.01 can cause problems?! blockstoavg=22 !If it hasn’t any previous values to check, where it will scan them from?! Did I miss something? And some other questions: Should we just start dcrwallet and unlock it (fully synced with dcrd)? Should we start dcrwallet with --enablestakemining or any other flag? Dcrticketbuyer will also be responsible for voting with dcrwallet unlocked? How the wallet is going to vote tickets if someone is solo PoS or wants to keep his wallet as a voting backup for the extreme rare case that all pool voting wallets may go down? Does fee settings on dcrticketbuyer overrides any other fee settings on dcrwallet? Running dcrticketbuyer the above way with fully synced dcrd and dcrwallet unlocked is similar to previous versions of dcrwallet running for auto-buying tickets? I know that v0.1.4 is currently marked as unstable but has anyone already tried dcrticketbuyer with no major problems on a mainnet stake pool? I think in the future stake pools should include instructions for setting up dcrticketbuyer as well and they can possible also provide a personalized .conf sample file download for dcrticketbuyer with at least ticketaddress, pooladdress and poolfees pre-configured. Information and instructions for dcrticketbuyer should also be added on https://docs.decred.org/ I hope everything in the code will be stable and refined as soon as possible and we will get a Paymetheus GUI Wallet with simple and advanced mode that will do all the basics for Decred, sync dcrd, wallet and have complete PoS functionality. This will bring more people to Decred. @_ingsoc A small typo maybe, v0.1.3 was released on May 10th 2016 not April 10th 2016. By the way, the new Decred Network Status dashboard: https://stats.decred.org/ looks good already.
Yup, you don't need to use dcrticketbuyer yet. But it is quite nice. But if you do use dcrticketbuyer, your wallet must be unlocked. dcrwallet still does the voting so you will need enablestakemining plus being unlocked if you wish to vote without a pool. dcrticketbuyer is a client of dcrwallet and dcrd, just to help you with buying tickets. Fee settings in dcrtickerbuyer apply only to transactions generated by dcrticketbuyer, AFAIK. But perhaps it makes persistent changes in some fees. You'd have to verify with dcrctl. I have been using dcrticketbuyer and it is working well, except for median fee estimation (stick with the default, mean). Some settings are a little counter intuitive and it tries to be very intelligent, so you will need to feel it out. Primarily maxpriceabsolute vs pricetarget is what you will have to toy with. There is interplay with price target and how many tickets are purchased per block, in order to slow or speed the price change. For your dcrtickerbuyer.conf settings, You can completely omit testnet=false, as mainnet is the default. maxfee really needs to be around 0.27. Yes 0.27. When price is low it becomes very competitive and can be difficult to get your ticket purchase mined. I set feetargetscaling to 1.07 to lead on fees and get mined perhaps a little faster. I haven't used http server, so I can't confirm that part You can safely increase maxperblock. I think it's mainly there to slow down the mob. maxpriceabsolute... I'd say go with 28. expirydelta is most useful with a lower number of blocks, maybe 18. If your tickets aren't mined in a dozen or so blocks, you probably have your fees too low. Set pricetarget to something other than 0.0 or it will use a price based on the 30-day volume-weighted moving average, which will probably end up being lower than you want to spend given the current trends. Around 25 now. My target is ~26. I commented maxpricescale and minpricescale as I'm not a fat-cat staker. p.s. The nodes shown on the dashboard at stats.decred.org are not all public nodes, as there are many with non-9108 ports, indicating they are inbound rather than outbound connections. The list seems to be from a dcrd's peers.json. It's an interesting snapshot of some nodes on the network, including peers who may not wish to accept connections at all, but it's not exhaustive and it's not the public nodes you might get from DNS seeders.
Did something change with the default max peers in this version? I used to have max 8 peers at any given time, now it's showing as 13, which is a good thing.
Hmm, i am still having difficulty with the dcrticketbuyer and i do not understand completely how it works and how it replaces the old method of ticket purchase. Does dcrticketbuyer need to be run only on its own? Or is it supposed to run alongside with dcrwallet? I tried running "dcrticketbuyer -C ticketbuyer.conf" with the above recommended settings for solo mining and I am getting error of : Failed to read dcrd cert file at C:\Users\xxx\AppData\Local\Dcrd\: read C:\Users\xxx\AppData\Local\Dcrd\: The handle is invalid. Why? In the meantime, i'll keep running dcrwallet 0.1.3 until things become clearer.
dcrticketbuyer cannot be run on its own. It makes connections to both dcrd and dcrwallet. The error you reported suggests that dcrd has not been run or was not run with the default appdata directory.
Both dcrd and dcrwallet is running and fully synced. What do you mean by "was not run with the default appdata directory"? I checked both of the appdata directory (dcrd and dcrwallet) and they do contain rpc.cert & rpc.key files. Please pardon my noobiness.
make shure you have rpc.cert and rpc.key files in your directory: C:\Users\xxx\AppData\Local\Dcrd\ you be forced to run your clients with TLS communication to use dcrticketbuyer
@gravityz3r0 Just realized what was wrong. You used literally dcrdcert=C:\Users\your_username\AppData\Local\Dcrd\, but you need the full path including "rpc.cert" Please use the documentation on the following page as reference: https://github.com/decred/dcrticketbuyer/blob/master/README.md