This development dispatch covers work completed since the Decred v0.1.1 release from April 25th, 2016. Since then, developers have merged 37 pull requests of code into 7 software repositories. New repositories were created created and populated for a consolidated miner known as gominer as part of RFP-5 and a statistical dashboard known as dcr-netstats as part of RFP-3 (in addition to decred-dashboard that is hosted at https://dcrstats.com). During this period, a total of 19 commits occurred in these repositories and represent modifications to the effect of 3,777 lines of code added to and 920 lines removed from the Decred codebase (dcrd, dcrwallet, dcrprclient, gominer). 25 commits also occurred in other Decred repositories (dcr-netstats, ccminer, cgminer). A series of RFP milestones were achieved and paid for from the development subsidy. Milestones paid for include (See: Status and Expenditures): RFP-6: Pool has been successfully tested for 1 week on testnet and configuration verified (x2) (1c640e9, ef20c2e) Binaries: https://github.com/decred/decred-release/releases/tag/v0.1.2 dcrd getstakedifficulty now returns the calculated stake difficulty of the next block. When the next block is a stake difficulty readjustment, users will now see the upcoming stake difficulty (137-8207e4d) Improved fee handling (139-c9a0afa) Moved non-mempool specific functions to a new file and added more test coverage (140-14c7cc9) Fixed an issue with mempool fees where the memory pool would incorrectly eliminate transactions sent over sendrawtransaction that had high fees while also always rejecting high priority transactions (141-4328736) Added a new estimatestakediff RPC command to estimate the minimum and maximum next stake difficulty. The caller can also estimate a new difficulty given a passed number of tickets to be mined in the remaining difficulty period (143-7fd213b) Added two new RPC commands designed for wallets running stake pools (stakepooluserinfo and addticket) (144-f1796b0, 148-084edf8) Added two new RPC commands to calculate the volume weighted average price of tickets (ticketvwap) and to get the transaction fee information for regular transactions in blocks, the mempool, and a height range (txfeeinfo) (145-29f116c) Updated documentation (147-5623458) and versioning (150-f93cb9f) Credits: @ay-p, @ceejep, @jcv, @raedah dcrwallet Added a non-default allowhighfees flag to wallet that enables users to send transactions that are not safety checked for high fees (214-ec2c1c2) Fixed an issue that could cause lock-ups in wallet (219-0e7558d) Improved error handling (224-d4ea045) Updated versioning (225-e545bec) Credits: @ay-p, @ceejep, @jcv dcrrpcclient Added a number of new RPC commands (addticket, estimatestakediff, settxfee, stakepooluserinfo, ticketpoolvalue, ticketfeeinfo, ticketvwap, txfeeinfo) (16-a5a51f5) Credits: @ceejep gominer Enabled TLS, improved configuration, added a sample config file, and updated licensing (3-39550c6) Updated configuration (1-d43cd3e, 2-43e6a84) Credits: @jcv ccminer/cgminer Deliverables from RFP-5 were released as updated miner binaries of ccminer (NVIDIA) and cgminer (AMD) for Windows and Linux (v0.1.0) (See: New Miner Binaries Now Available). Credits: @chappjc, @jcv, @jolan, pallas1, @tpruvot, @Wolf Developer Notes Added stake pool fee functionality We have added new config flags for dcrwallet. Let's go over each option to make crystal clear its usage: stakepoolcoldextkey When this option is set it turns on stake pool functionality for wallet. When stake pool is enabled for wallet, there are a series of transaction checks to verify whether this wallet will vote for a ticket that has used this stake pool's address as the ticketaddress. This option requires the extended public key of the stake pool's cold wallet that will receive the pool's fees. So on simnet for instance this option looks like this: Code: --stakepoolcoldextkey=spubVWAdividNTiSM9SdLRA5JX6LYNwt58cd51TFnpnULGQ8oqNMNskfkQwU7rjWMCY7phBguVr4XTmAWyDVRKpo2dFyjFb6QG4ihB8w64UPNuu:1000 The first portion (spub..., or dpub... on mainnet) is the extended public key and the second (1000) is the number of addresses to derive. Every user of the pool gets their own cold fee wallet address derived, so we recommend using at least 1000 in anticipation of the relative number of users in the stake pool. When a vote is created by the stake pool to vote on a ticket that has been given voting rights, it pays the pool fee to the address derived for the cold wallet from this extended public key. pooladdress This is for use by the stake pool user. It will be an address provided to the user by the stake pool. If set, this address is used during ticket purchase and will commit to a small output in the ticket that gives the stake pool its required fees. ticketaddress Same as the old option. This is the address that the stake pool user is giving the ticket's voting rights to. poolfees This is the required ticket fee as requested by the stake pool. The value set by the user needs to be greater than or equal to that of the pool. The fee is a percentage based fee, based on the stake subsidy. Here is a concrete example from simnet: The ticket price of this ticket was 46.0551008, and the ticket relay fees were 0.00000100 per kB. The pool fees were set to 1.00%. The subsidy on simnet at this block height is approximately 29.40888 Coins per vote. This is the ticket as purchased by the user: Code: "vin": [ ... , ], "vout": [ { "value": 46.0551008, "n": 0, "version": 0, "scriptPubKey": { ... , "reqSigs": 1, "type": "stakesubmission", "addresses": [ "SsYZMHeeixdNRTkk6afzHBPL4unYDsFNd4r" ] } }, { "value": 0, "n": 1, "version": 0, "scriptPubKey": { ... , "type": "sstxcommitment", "addresses": [ "Ssghjx8PvQVV3FM3w5FcGi9kWGvDpDkQDTV" ], "commitamt": 0.17948021 } }, { ... , }, { "value": 0, "n": 3, "version": 0, "scriptPubKey": { ... , "type": "sstxcommitment", "addresses": [ "SsYUi5tbXfqHnTPgvHcajNW4yiGeSP6n7Xq" ], "commitamt": 45.87562609 } }, { ... , } ], And here's the vote that the stake pool created for that user's ticket: Code: "vin": [ { ... , }, { ... , } ], "vout": [ { ... , }, { ... , }, { "value": 0.2940888, "n": 2, "version": 0, "scriptPubKey": { ... , "type": "stakegen", "addresses": [ "Ssghjx8PvQVV3FM3w5FcGi9kWGvDpDkQDTV" ] } }, { "value": 75.16989347, "n": 3, "version": 0, "scriptPubKey": { ... , "type": "stakegen", "addresses": [ "SsYUi5tbXfqHnTPgvHcajNW4yiGeSP6n7Xq" ] } } ] As you can see '"n": 2,', the third output, is the stake pool fee of 0.2940888. This is 1% of the vote reward at that point (0.2940888/29.40888). The remaining subsidy and the original coins are returned to the take pool user in output '"n": 3,'. For more information about stake fees, please refer to dcrwallet/wallet/txrules/doc.go.
I had been using the official stake pool. Now with some additional commands in place do I need to change the commands I used before or those will work fine?
@ceejep @_ingsoc On v0.1.2 with all these new things like pooladdress if we are running dcrwallet for auto-buying tickets for the official stake pool https://stakepool.decred.org/ like this: dcrwallet --username="dcrwallet_username" --password="dcrwallet_password" --walletpass="public_passphrase" --dcrdusername="dcrd_username" --dcrdpassword="dcrd_password" --enablestakemining --balancetomaintain=x --ticketmaxprice=x --ticketbuyfreq=x --ticketaddress=Our_P2SH_Pool_Address do we have to change or add something on the above or we can start the dcrwallet exactly the same like v0.1.1? I really need to know this before I'll update to v0.1.2 .
I get the following output on the Wallet when trying to use version 0.1.2, reverting to 0.1.1 Code: 21:45:51 2016-05-04 [INF] RPCS: Listening on 127.0.0.1:9110 21:45:51 2016-05-04 [INF] RPCS: Listening on [::1]:9110 21:45:51 2016-05-04 [INF] DCRW: Attempting RPC client connection to localhost:9109 21:45:51 2016-05-04 [INF] CHNS: Established connection to RPC server localhost:9109 21:46:17 2016-05-04 [ERR] DCRW: recorded version 2 is newer that latest understood version 1 Linux ARM(not the 64-bit one) build running on a Raspberry Pi 2 B
The mainnet pool is without fees right now. Eventually it will probably close to give way to pool requiring fees. For now with this pool, the commands do not change.
Strange, you seem to be on right version of wtxmgr DB: https://github.com/decred/dcrwallet/blob/sync/wtxmgr/db.go#L142
There seems to be a strange error, I have not noticed before. If I start the daemon, I have to wait 2 minutes to sync things. Then start the wallet, it is ready in seconds. But if I stop the wallet and then start it again, it never starts properly. I have to stop the daemon - but it never goes past "BMGR: Block manager shutting down". I have to kill it, and start again and wait 2 minutes .... Version 01.02 testnet. It is certainly not the case with 00.10 mainnet which works fine afaik. And the problem with high fee check introduced in 01.01 is still present - I have to use allowhighfee option
There was an odd condition on testnet where nodes kept rebroadcasting orphan transactions to each other. The fixes have been pushed. You'll either need to build from the latest git or wait for a new release.
It really helped, seems fine now (testnet) Also i had a problem with ticketpurchase version 01.01 saying "client shutdown" and "[WRN] WLLT: Failed to send raw transaction: -22: TX rejected" ... "has 5863689 fee which is above the allowHighFee check threshold amount of 2960000", but it seems to be corrected in 01.02 (--allowhighfees wallet flag is used). Great work ! There is one more thing - I missed votes for hundreds of tickets in testnet (from git) - seems like --enablestakemining flag is required for a wallet to be able to vote ? Not sure if it was the case before, but I'd say it is really worth mentioning somewhere (help, log). Or did I do something wrong ?
Yes that flag has always been required to vote. You can also put enablestakemining=1 in dcrwallet.conf. It does print: Code: [INF] WLLT: PLEASE ENSURE YOUR WALLET REMAINS UNLOCKED SO IT MAY VOTE ON BLOCKS AND RECEIVE STAKE REWARDS if you enablestakemining is on. Good point though, It definitely should remind you to turn it on if it's off.
I would say don't put enablestakemining=1 to vote without also putting a balance to maintain, or a maxticketprice, or you'll automatically start buying tickets at whatever the current price is as well as voting!