Dear all, I am worried a bit with recent development of Decred. A lot of work and money were recently put into PoS pools to work and to be able to charge fees. It seems that most of older RFPs were put to hold. I understand priorities may change, but I do not like it still. It worries me even more that devs first mentioned that it is not a good idea for PoW pool operator to own a PoS pool, and yet they allowed couple to have just that. Check here https://forum.decred.org/threads/rfp-6-setup-and-operate-10-stake-pools.1361/page-2#post-17007 I do not know if they own serious part of hashing power, but as ticket price wars got more tough recently, as a PoW pool owner you can select your preferred tickets. I am not saying they do it, just that they can. And I saw cases of tickets mined with smaller fee, than fees in mempool. The reason may be old code, but how many miners with 0.0.10 version can be out there ? I would be glad if somebody can ease my worries and clarify the future plans a bit.
Hey @.m., thought I'd offer a response. You're not making an unfair point, but I do want to take a step back and look at the situation carefully. So ideally, you wouldn't want a PoW pool operator to own a PoS pool. If you look at the members of the each stake pool, all 25 of them who joined the project, you will see that only one person out of 25 owns a PoW pool that currently contributes <3% of the total network hash rate. The important distinction to draw here is that when it was first raised, the person in question came forward and explained that they are involved solely in a technical advisory capacity with that PoS pool, which means they are not the owner and not involved in the decision-making capacity of that PoS pool. That may sound fancy, but the reality on the ground is that in a highly specialised field like cryptocurrency development, there are very few technically skilled people willing and able to participate. You are absolutely going to end up with some unavoidable overlap. Should the project shun away people who have contributed to it and continue to do so? I personally do not think that would not be in the spirit of what everyone is working toward. If it were (1) a large PoW pool owner who (2) wants to own a PoS pool, then yes, that would not be acceptable. The reality is someone who contributes <3% of the network hash rate through operation of a PoW pool (not them personally), who does not own a PoS pool but participates in its technical operation (not decision-making), and is one out of 25 people involved in PoS pool development, should not be disqualified from the process. That is a tiny amount of overlap in real terms. I'll try and get you a more technical discussion on the topic too if you'd like, since you raise technical points as well. It's important to remember that in any system you can isolate some element of it and ignore the larger process. Very few processes are perfect, but in the larger scheme of things, the PoS pools are a dramatic and successful step forward in voting accessibility (which means representation for users), and the project is honoured to have had so many great people join it. I hope that helps clear things up from the project side at least. In terms of older RFPs being put on hold, that is not the case. On the contrary, RFP-3 and RFP-4 are complete. @jrick is progressing on RFP-1, which was underestimated, unfortunately, but a reality of software development. @Dyrk is chugging along on RFP-2 and a heavy contributor to Decred in general. RFP-5 is complex and involve many people, but @jcv and @jolan are moving as fast as they can on gominer at present given all their other responsibilities. RFP-6 is very successful given that 25 people are involved, with 7 stake pools launched. RFP-7 is already underway with an announcement pending, and RFP-8 was just announced with @kefkius joining the project through his work on transaction scripts. Not saying every RFP is going to be a success or without bumps, but so far the process has been very healthy with real and usable outcomes produced.
@.m. I can confirm that work on RFP-2 is in progress. Last few weeks I was a little busy with other projects (Stakepool, Dcrstats and many tutorials, guides, articles, forum posts etc.. the latest one I published just an hour ago, because it seems to be really confusing for newcomers: Different types of the fee, in the last "under 18 dcr" round I found in stakepool logs 118 refused tickets because of low transaction fee, so they were never mined into the block ). I did a lot of work on RFP-2 (add support of PoS-mining using stakepools to the Web Wallet). And of course I'm very interested to finish it as soon as possible, because 10 new stakepools are launching and web wallet is a good tool to involve new users in Proof of Stake.
At the moment voters don't get a share of the transaction fees, so a miner doing this would be depriving themselves of 20*(FEE) to save 20*(FEE) when mining their own tickets into a block. I don't think that's an issue. The real issue, is a PoS pool having enough votes to pre-mine blocks, with the selfish miner attack. That requires ~30% of the hash power to be effective, though.
You are right to point out that according to the Proof-of-Activity paper by Bentov et al, a PoW pool operator being involved with a PoS pool, i.e. stake pool, is a potential threat. Note that in this case the PoW pool in question has a small amount of hash power (<3%), individual users of the PoS pool can verify their votes are being cast as desired, and that users are free to discontinue use of the PoS pool if they disagree with its actions in the context of voting. One constraint from RFP 0006 is that stake pools are soft-capped at 5% of total stake during bringup, so even if Epsylon3 were willing and able to manipulate PoS voting, his influence would be limited. My expectation is that any stake pool found to be using questionable practices would likely have its users simply move to another pool, which creates an incentive to not engage in bad behavior. At worst, this would allow an "exposed" manipulator a few months of waning influence before their stake pool runs out of tickets to vote as users migrate away. Scenarios like I describe above are exactly why we have pushed to bring 10 stake pools online and soft-cap their share of the stake. There was bound to be a lull in perceived output in the development process for the first few months after launch. In the effort to get Decred launched in a timely fashion, the developers could not fix or find every bug along the way. Over these first few months, user reports have helped shake out many bugs and that process is slowing down, which is what we expected to see. Now that most of the substantial issues present at launch have been fixed and the stake pools are on mainnet, we are working to get the next phase of Decred underway. Properly functioning stake pools are a prerequisite to allowing stakeholders to vote on hard forks, which will be explained in greater detail in a roadmap we will release in the next several days.
Thank you for explanation and all your hard work . I can see a better picture of the future of Decred now.