This development dispatch covers work completed since the Decred v0.0.8 release from March 18th, 2016. Since then, developers have merged 21 pull requests of code into 3 software repositories. During this period, a total of 25 commits occurred in these repositories and represent modifications to the effect of 8,622 lines of code added to and 13,221 lines removed from the codebase. A new request for proposal (RFP) has been opened to establish and operate additional stake pools in a number of geolocations. Several parties have stepped forward, and the project is working with them to set up the new infrastructure. Design deliverables for RFP-1 by @linnutee are nearing completion, the first component of RFP-4 by @Shadowlance is complete and will be integrated into a documentation system in the future, and a number of milestones are being completed and put into Decred repositories for RFP-5 by @ocminer, @tpruvot, and @Wolf. Work continues on RFP-1 through 6. Finally, Paymetheus, the Windows wallet GUI for Decred has been made available as a testnet pre-release prior to the completion of RFP-1's improvements. Binaries: https://github.com/decred/decred-release/releases/tag/v0.0.9 dcrd Added new IsUnspendable function required for the latest dcrwallet sync that takes a public key script and returns whether it is spendable (96-5fcef8a) Removed an extraneous check (98-7a15800) Updated versioning (97-5fcef8a, 99-0ed0e81) Credits: @davecgh, @jcv, @jrick dcrwallet Corrected and simplified shutdown logic for interrupts (127-2b79aad) Disallowed naming accounts with an empty name. Any accounts in the database that are already named the empty string are left untouched and should be renamed to something meaningful by the user (127-9fe02c4) Made wallet manage wallet database namespaces from the wallet package (127-fcccae3) Prevented a race when setting a new relay fee through the legacy RPC server (127-d09c2a8, 127-d09c2a8, 127-5d6392b) Refactored wallet transaction creation code (127-f084802) Removed legacy JSON-RPC notifications (127-6cf22b7) Updated logging for wallet locks and unlocks (127-6e6cb30, 127-71649ab) Updated startup configuration (127-cee0411) Synced dcrwallet to the latest btcwallet branch master branch. Includes general all around cleanups, pulls in new packages for improved transaction creation and fee estimation, which is now used when creating basic p2pkh transactions. Fee estimation constants and test vectors have also been updated for Decred's transaction sizes (127-2133b7b) Added a new wtxmgr API for resumable, incremental input selection that is performed under a single database transaction, and hooks up the API for transaction creation in the wallet package (130-b0aff95) Fixed updating the UTXO set for imported addresses to always update spending data even if the transaction already exists (133-a488b38) Refactored address pool code to scale to more accounts than the default account, updated address pools to be generalized so that in the future they can be multi-account, and greatly simplified logic for the address pool. Accounts are automatically resynced when the wallet is restored from seed (134-4b64adf) Removed voting pool package as it is currently unused in Decred (135-d98dc43) Ensured resync has been completed before launching notification handling so that wallet would not drop or mishandle notifications that came in synchronously when wallet resynced (136-6bf720c) Fixed proportion missed calculation in the getstakeinfo RPC request (138-1a89f7e) Increased test coverage by fixing waddrmgr tests (139-b110e4e) Modified logic for password prompting (142-5141dfa) Added safety checks for address pool access to ensure that the address pool exists and has been initialized before calls to its functions or internals (143-125bbdd) Fixed various issues identified by the static checkers (144-0c80297) Updated licensing (127-5140086), RPC naming (127-82e7437), documentation (127-397bead), and versioning (126-0d61bd9, 127-b1500ba, 150-4387fa3) Credits: @ay-p, @ceejep, @jcv, @jolan, @jrick dcrutil Updated test coverage so all tests pass successfully (4-9d5a582, 6-5f2e3d6, 8-36d88d9) Updated versioning (7-9bb7f64) Credits: @ay-p, @jcv RFPs Added RFP0006: Setup and Operate 10 Stake Pools (15-7bf1adb, 16-ac8847e) Credits: @dhill
So much ppl still at 0.0.1; wondering if it will create issues one day. 09:15:43 2016-04-02 [INF] BMGR: New valid peer 31.14.131.236:9108 (outbound) (/dcrwire:0.0.1/dcrd:0.0.1/)
How to prevent "dust" ? While trying to buy a ticket I got- -4: not enough to purchase sstx I think its due to coins in too many addresses. Correct? *POS Mining* So I have to consolidate wallet again? And how to use the .... reuseaddress command and whats its function
Is there some kind of "incentive" we as a community can do to encourage people to upgrade to the latest stable build? Will there be a problem across the network eventually with people who do not upgrade? I'm seeing a lot of old versions also connecting as peers. Perhaps: Auto-update feature that can be turned on/off. FAQ with bullet points to show the benefits of the upgrading. FAQ with bullet points to show current version and problems they will have if no upgrade. If re-index is needed, do it for them with a flag rather than re-import of seed. Flag to accept peers only that are >= v.#.#.# I don't trivialize the programming effort for these points above, as I know some of them are tremendous and would require that every "release" should be vigorously tested before any auto-update feature is implemented.
Could that not be done as a broadcast message? A simple flag with the current version number could trigger a in-built message such as "You are running a old version of Decred, please update ASAP."
Telling them through a message is not really incentive tho. Allowing the new stable versions to disable them as peers is a strong incentive. Perhaps as a default, any version that is 3 versions lower or more get excluded? The upgrade binaries is not that bad, but the re-build from seed should be built in with at least a command to do it for you if needed. I was sitting there for 20 minutes waiting for the latest block to load before I had the courage to start my wallet or it might have made me start over because of an error or something. Remember version 0.0.8? I had to do that 4 times before I got that right. Then there's the auto-update flag that detects the latest version and does the upgrade for you. This would help a whole lot in keeping the community in sync much more than a punishment of peer blocking lower versions, but I'm up for either/both if needed to keep everything moving. Basically, we need a painless upgrade path that's built into the infrastructure.
I ended up recreating wallet from seed. There was a bug in the previous versions where in tickets value after they were used up didnt become 0, So I was shown a balance of 400DCR, but now its fixed and as I created the wallet the balance issue got resolved. If anyone who is POS mining is facing the issue of Increased balance being shown, Please create ur wallet from seed.
I am having this issue: http://i.imgur.com/ZuzSNmU.png I guess even I am being shown increased value? hence I am unable to send this amount of DCR even though getbalance shows me I have more than the amount I am trying to send. Just one question.. recreating the wallet from seed, wont it result in some addresses being lost?
Another person had the same problem Recreating the wallet from seed solves the problem. And balance issue also gets resolved. And I don't think u will lose any addresses. Ur wallet should be in same proper condition. Steps to recreate- First backup the old dcrd and dcrwallet folders. Then start dcrd command and WAIT FOR IT TO SYNC TO LATEST BLOCK. After it syncs to latest block create the wallet. If u use stake pool u will have to import the script again. Atb.
I confirm that wrong balance display issue is fixed after re-creating wallet from seed with v0.0.9 . On dcrwallet first run it asks at the same command prompt window for your private passphrase to unlock your wallet and then it starts syncing, after that I also re-import script from pool and it re-syncs again and finally it returns the correct balance with --wallet getbalance * 0 all . Great release! @ceejep I still get "[ERR] WLLT: Cannot handle chain server voting notification WinningTickets:..." message when one of my ticket on stake pool gets voted. I don't know if it's just a display issue or my wallet doesn't have voting rights over my pool tickets but anyway it's not a real problem since it's very unlikely my wallet will vote for them before stake pool does or fails to vote. I just mention it.
i have this message when i try to send some cooins from one address to another: -32603: -22: TX rejected: tried to spend zero value output from input 389c049f4 992c8985fb30564a59fd3daabd52f52f31dcaa5902408f53aef009, idx 2 my balance of spendable coins is higher that i want to send