This development dispatch covers work completed since the Decred v0.0.10 release from April 7th, 2016. Since then, developers have merged 28 pull requests of code into 4 software repositories. During this period, a total of 28 commits occurred in these repositories and represent modifications to the effect of 1,991 lines of code added to and 602 lines removed from the codebase. A series of RFP milestones were achieved and paid for from the development subsidy. Deliverables from the milestones will begin appearing in the Decred ecosystem in the near future. These include another network overview and indicator dashboard (RFP-3), a new documentation system available for community feedback and contribution (RFP-4), new and updated binary builds for Windows and Linux for cgminer and ccminer (RFP-5), and new independently-operated mainnet stake pools (RFP-6). Milestones paid for include (See: Status and Expenditures): Final modifications and documentation in RFP-1 (423fd36) Generate copy for obtaining Decred funds, using the block explorer, and PoW mining documentation, and review and provide feedback on copy for introduction, wallet setup, stake mining and network parameters documentation in RFP-4 (14e3bb1, 682b50a) Pool has been successfully tested for 1 week on testnet and configuration verified in RFP-6 (x2) (d99401c, 74faad5) Binaries: https://github.com/decred/decred-release/releases/tag/v0.1.0 dcrd Fixed constructors for new RPC account commands (106-0119cd6) Added option to change the home directory (109-851569f) Fixed fall through on invalid transaction types for getrawmempool (111-2459171) Merged policy.go changes from btcd to fix fee calculation issues (112-936b379) Fixed an issue with the mining transaction selection algorithm where it failed to sort stake transactions effectively. The codebase now defaults to no priority size spacing in the block, correctly sorts transactions by their stake importance, and then sub-sorts them by fees (113-2ba4225) Fixed an issue to ensure proper handling when attempting reorganization to an eligible block (117-b75a280) Fixed getrawtransaction verbose output to correctly display ticket commitments (address and amount) (119-678b454) Modified the purchaseticket RPC command to add new fields now used by wallet (121-ca8935f) Improved error handling for transactions (122-9559b0a) Updated configuration (107-073d412), documentation (118-5c79172), and versioning (123-a339852) Credits: @ay-p, @ceejep, @jcv, @jyap, @Reiuiji dcrwallet Fixed an issue that could cause an unusual locking up of the wallet when requesting a transaction, such as through sendtoaddress. The address is pulled before the database transaction is opened and then committed to later if the transaction succeeds and includes the change address (167-eb9d082) Fixed attempted syncing when connected to an empty chain so cold wallets connect properly (169-d519d55) Fixed an issue with getwalletfee consistency (172-bce92a7) Added a sweepaccount tool that creates on-chain transactions, one per used address in a source account, to sweep all output value to new addresses in a different destination account (173-a4b8c49) Fixed an issue in address manager sync error handling (176-5166dcc) Fixed an issue in wallet auto-syncing for wallets synced from seed (177-6be3794) Changed default relay fees from 0.05 to 0.01 DCR per KB (182-adc0d74) Replaced ticket purchase code with new and more robust code. Chains of tickets can now be purchased with ease because outputs to be consumed by tickets are now pregenerated in split transactions. Ticket expiry can now be added to ensure that the tickets will expire in a short time frame, so that the end user can update the ticket fees if their tickets fail to be added to a block. Tickets can now pay a fee to a pool that is set by the user. The fee determines the amount that the user will contribute to the pool. The pool then receives this amount plus subsidy (183-780c3ce) Refactored address index syncing code to enhance the synchronization speed of wallet on restore from seed and start up. A new flag has been added to allow users to optionally set their final address index scan lengths (184-286287f) Updated configuration (168-d45ff26), user prompts (180-2e788aa), and versioning (185-b192834) Credits: @ay-p, @ceejep, @jcv, @jolan, @jrick dcrrpcclient Added RPC client handling for the new RPC commands in dcrd (existsaddresses, livetickets) and dcrwallet (accountaddressindex, accountfetchaddresses, accountsyncaddressindex, walletinfo) (12-e297cfc) Fixed purchaseticket caller (14-f005c4a) Updated configuration (13-3a9c419) Credits: @ceejep, @jcv dcrutil Updated configuration (9-74563ea) Credits: @jcv
Updated and I hope everything will work as stable as possible. Decred developers keep up the great work! Can we set the fee values lower than 0.01 DCR without any major problems? Is there something https://stakepool.decred.org/ users have to do about it now?
No, this is a first step towards supporting stakepool fees so new stakepool operators can be compensated. Nothing has changed with the C0 pool at this time.
If anyone else is receiving this error since Dd6 0.10 release: Code: Enter private passphrase: Failed to input password. Please try again. Please run dcrwallet plain without any arguments and allow it to prompt you to input your private password for the first time so it may "sync your accounts." This will allow you to run your startup scripts as usual. I was unable to run dcrwallet even with only nohup before I examined this. It doesn't seem to affect wallets that are already online and functional upon upgrading their binaries, and has only affected me while erecting an entirely fresh wallet/node. Hope this helps someone. It's a seemingly complex problem with an extremely simple solution, thankfully. Thanks for the constant work devs I am an absolute DCR fanboy; you guys are brilliant.
Upgrade went well yesterday, I thought I'd let it run for a bit before posting. Shut down wallet and server. Copy new binaries over old binaries. Start up server and wallet. Thank you devs for all your hard work! Edit: Actually got my DCR back because the tickets that were automatically purchased didn't get added to the block chain.
Updated without problems but now I am getting constant errors on trying to purchase a ticket. Any ideas? 05:23:45 2016-04-21 [ERR] WLLT: PurchaseTicket error returned: -22: TX rejected: tried to spend zero value output from input fe760fecd8d38e1edf369fca989aa49e954 a637f860f796451cf6ef9e85cc20c, idx 2 EDIT: Recreate the wallet from seed did the trick, can buy tickets again.
This guide helped me. https://forum.decred.org/threads/how-to-rebuild-resync-wallet-successfully.1338/
@_ingsoc @ceejep @jolan Something went wrong with default ticket fee after upgrading from v0.0.10 to v0.1.0. I was away from PC but I have left wallet unlocked and running for auto buying tickets for my pool address without changing the new default ticket fee of 0.01 DCR (dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet getticketfee also returned 0.01 after the wallet get started). I see now that my wallet made some ticket purchase transactions which all of them failed to be included to mempool (no change in getstakeinfo or in pool site tickets section) but most of these purchases from what I get on block explorer were made with fees lower than 0.01 DCR. They were might failed to enter mempool due to low fees and the very low price ~ 6.5 DCR, sad I missed that price but anyway even a fee 0.01 was too low for that price but the problem is the strange fee values like 0.00419 and 0.00253 which were not set by me. In v0.0.10 I didn't had such a problem. Also if I am not wrong if a ticket was failed to get included in mempool the fee was returned to balance with the funds spend for buying that ticket and also the transaction hex returned "No matching records found!" in block explorer. But in the above case the fees weren't returned (it's only ~ 0.05 DCR in total so not a big problem for now) and I can see that the tx hashes of these tickets purchases have some confirmations on block explorer although they failed to enter mempool. I maybe be wrong about this 2nd paragraph though. I restarted wallet and use dcrctl -u "dcrwallet_username" -P "dcrwallet_password" --wallet setticketfee 0.01 to see if that will fix the above spend ticket fee value problem. Should I recreate wallet from seed with v0.1.0? Should I go back to v0.0.10 and in this case will I have any problems if I only change the dcrwallet.exe to the older one? Anyway I think I'll leave it as it is for now and I hope it will be fixed in a new version soon.
The ticket purchase code changed with the latest version to automatically consolidate the amount needed for a ticket with the fee in a regular transaction, then purchase the ticket with no change, instead leaving the change in a regular transaction so that it won't get stuck leaving the user completely unable to spend the remainder of their funds. The side effect, as you noticed, is that the transactions generating outputs to be consumed as tickets go into the blockchain even if the tickets fail to, spending a small amount of fees. The automatic ticket purchase code was only intended to be used for simulation testing originally, but this sort of thing tends to get picked up and then never dropped. So, it's a trade off. Most people want to be able to spend their funds and not have them stuck while they wait to see if their ticket will ever get into a block. I'm working on a simple, customizable drop-in replacement for automating ticket purchase ASAP, using the RPC client code. Today I got a new RPC call for daemon merged that tracks fees in the mempool, current blocks, and previous whole difficulty windows. The new ticket purchasing bot will use the purchaseticket RPC API directly and track fee indicators for tickets along with difficulty, and spread ticket purchases over multiple difficulties while still attempting to get the majority of tickets for the lowest price. There was also a bug in wallet before where ticket fee wasn't selecting fees per KB. This has been fixed and setting the ticket fee now sets correctly. Because of this, it looks like people were setting their fees much to low with the new version. The new ticket purchaser is coming, but one thing at a time. Sorry to not have clear documentation for the API change, but we're also trying to get stakepools up to speed ASAP and there's a lot of work to be done in a short period of time.
So it's auto consolidating to ticket price now? And these low 0.00x fees I see in those tx outputs were spend for consolidations? Well I preferred the previous behavior but if that would be better for the majority of Decred users then it's OK. It would be better though if there was an option for "turning-off or on" this "auto-consolidation" behavior. Of course I understand you have a very busy time and a lot of work. Thank you very much for the explanations and your time. Good to know I didn't miscalculated anything and my wallet balance returns are correct.
Well, I also noticed than my many ~6 DCR ticket purchases didn't get added and my money returned. What do we do now?