Greetings, We are pleased to announce that the mainnet stake pool is now available at https://stakepool.decred.org. A stake pool allows you to purchase tickets and have the pool redeem and vote on your behalf. This is perfect for people who wish to take part in Decred's proof-of-stake (PoS) mining but cannot do so due to a range of factors: You do not want to keep a wallet unlocked constantly You lack a reliable, fast, and low latency Internet connection You do not have access to hardware that is online 24/7 for months The development team intended to have the mainnet stakepool released as soon as possible but unfortunately it took longer than we initially estimated due to: working through operational issues like how to properly re-sync a wallet to the cluster after disk/network failure statistical/accounting bugs due to how a cluster of wallets operates multiple refinements to the code/logic to better handle temporary failures While we're confident that we've worked out all of the issues we've experienced while operating the testnet stake pool, it's certainly possible that new issues may arise. Our plan is to: start preparing the source code for release fix any and all issues that arise on the mainnet pool release the source code a week from today The ideal distribution for decentralization would be for 20 stake pools to have 5% stake and for the operators to be run by public identities that do not have any ties to an exchange or mining pool. We will be providing assistance in the way of documentation and support to help interested members of the community become stake pool operators. Sincerely, Decred Project
I will make a note of this. There will need to be plenty of stake pools, and the project will lend a hand to those who are serious about setting up and maintaining a stake pool. The next priority is getting to know who the interested parties are and working through that process with them when the code is ready.
Thank you! That is great news. So now probably also RFP-2 (upgrade web wallet to support PoS-mining in the pools) are ready to go. I am also interested to host PoS-pool, but probably with splitting of the reward between all participants based on amout of the live tickets they have in the pool. I think it solves the biggest problem of the PoS-voting, that your money can be locked up to 5 months. In such pools you will get some guaranteed spendable coins every day.
Can I ask will there be any % of a PoS reward given to the pool owner? And what kind of machine and connection you need to host it?
Yay, I've successfully purchased my first ticket ever..! At the sky high price of 14.13 DCR. Totally worth it. What I don't yet understand, is how the pool controls my funds. For example, when I used "getbalance" just after I bought the tickets it displayed 0, and when I checked my webwallet it confirmed that all my funds had been transferred (I used option B: dcrctl --wallet purchaseticket "default" 15 3 Dcsg3D17iexampleaddressgf9kELijVrzf). As I'm still a newbie, I first thought that someone scammed me. Then, after waiting some time, I used "getbalance" again and my balance was nicely what it should be. My best guess is that my funds returned after my "wallet unlock command" timed out? Furthermore, as you can see I allowed the stakepool to buy 3 tickets at 15 DCR each (max price). How can it be that it only managed to buy one? Is there a way to control the spending more precisely? (I guess didn't give my wallet enough time to be unlocked?) Also, can I close the command lines after I have given the buy order? And does it make a difference whether I use option A or option? Hope these questions make sense to you (and please excuse me if the answer is obvious, I'm still a newbie). Thanks for the release dcrdevs, I'm very impressed! EDIT: my webwallet still thinks my balance is 0, while "getbalance" displays my real fund (original fund - ticket price - fees). Why is there a difference between the two? Is it better to stop using the webwallet while staking? (sorry for yet another question)
@VanQ when you are solo staking your wallet has to be unlocked and online 24/7, because when your ticket gets called (this happens randomly) you have to reply, otherwise you'll miss your vote. When you are using the stake pool you basically give the pool the authority to vote for you. This way you don't need a wallet up and running all the time. Did this answer your question?
Nice! Looks as if the pool did spike the price quite a bit. It would be nice to have a computed value for the command line like AvgSStxPrice. This would allow --ticketmaxprice=AvgSStxPrice. We could set it and forget it and the ticket price would smooth out quite a bit. I don't even know if using a computed value for that command is possible. Right now I am adjusting the max price manually and am getting some pretty good deals, it seems. It just seems as if it would be good for the community overall to offer that functionality.
Bill Threewits: what logic do you follow when you manually adjust the maxticket price if I may ask? what's your reasoning ?
Good job OP with the stake pool. What would be the best way to "shift" from solo staking to pool staking, if all my coins are already solo staked at the moment? Run with -enablestakemining and -maxticketprice=0 and start staking the coins I slowly get back through the pool?
This pool absolutely does not control your funds. It does not have your private keys, so there is no way for it to do so. The reason your balance appeared to disappear until a block or two later has to do with the fact that the getbalance command, unless you specify "all", only lists your spendable balance. Whenever you spend coins, it consumes one or more unspent transaction outputs (utxos) and sends the specified amount to the specified address and a second output back to a change address that you control. During that time, the change has zero confirmations and so it won't show up as spendable. That is why your balance was correct after a block or two when the the change became spendable again. The timeout of the unlock command has no correlation here. When you say you allowed the stakepool to buy 3 tickets, that is not correct for a couple of reasons. First, the stake pool does not have access to your private keys, so there is no way it could purchases your tickets. Instead, you purchased a ticket and granted its voting rights to the pool. Second, you told it to purchase a single ticket with a max price of 15 DCR using only coins (technically unspent outputs) that have at least 3 confirmations (at least 3 blocks have been added to the chain after the coins were received). As we can see from the help for the purchaseticket command, the parameter after the spend limit is the number of minimum confirmations required: Code: $ dcrctl --wallet help purchaseticket purchaseticket "fromaccount" spendlimit (minconf=1 "ticketaddress" "comment") Correct. You don't need the wallet running anymore when using the stake pool because it will vote on your behalf. However, in reality this pool is designed such that both you and the pool have voting rights, so you can leave your wallet online as a backup to the pool if you really wanted. Option A is more of a "set it and forget it" mode while option B allows you to purchase tickets exactly when you want.
Good idea, but the way the wallet is written it's not possible. TicketMaxPrice expects a floating point number to be given from the CLI.
I use @Dyrk's website called dcrstats. I watch the average price paid, the size of the mempool and the fees paid in mempool to buy when the price is at or below the average. I raise my fee paid per ticket if the average fees go higher and the line is long (mempool large). Hope this helps everyone.
Thanks for the info; I thought that might be the case. Well, maybe a pool/wallet programmer can work with the idea.
It is quite easy to do with cron job + bash script which will check current avg price, compare it with your max price and restart wallet if needed. Which OS do you use? UPDATE: oh, I forgot, now probably there is even no need to restart wallet because in v0.0.6 devs introduced new call: Code: dcrctl --wallet setticketmaxprice