@jolan: What is the closing date for this? @jy-p: That's quite an elaborate setup. What do you consider the the minimum setup for a stake pool? 2 voting wallets on different root servers? Necessarily different physical locations? I don't quite understand what exactly you gain by separating dcrd from dcrwallet. You hide the IP of the voting wallet which makes it harder to hack and DoS the wallet server. But there is not much to gain on the wallet server anyway. Am I missing something? Do you consider such a setup necessary for a minimal stake pool? It doubles the number of necessary servers/VPSs.
The market will decide this. There will have to be some fee, and the single site pools won't be able to charge as much. But I do love the idea, and right now I and @ClokworkGremlin and "one other party" are talking about a high end solution. (Including shared pool voting for when the ticket prices get high)
This can be done with 1 front end web server for interacting with the users and 3 back end VPSes running both dcrd and the voting wallets right? I am ready to host as many machines as required.
I agree with you that the market will decide what solution is sufficient. That said, due to the nature of PoS voting, we feel that a higher level of redundancy than most people would consider typical is appropriate here. The motivation for posting our c0 setup was to make clear that there needs to be some kind of standard for stake pools to be considered 'safe' vs someone just running everything on a single machine at their house.
After reading the comments here and on IRC, I believe it is acceptable to run a pool with only VPSes and no physical machines. The requirement of using your own metal and multiple uplinks is beyond what most people are capable of doing. Many VPS hosting providers have multiple datacenter locations throughout a given country, so you can simply get 3 or 4 VPSes from a single provider at multiple physical locations. A minimum configuration would likely consist of 3 VPSes in separate physical DC locations: 1 for web frontend, 2 for dcrwallet+dcrd combinations. When you are hosting on your own metal at a location, you typically do not want to bleed that IP address since a DoS at that location may require you to physically move that machine. Since most of us don't have an abundance of distinct uplinks, this means that scenario can create a big problem and exhaust our supply of locations we can host these wallets. You are correct to note that there is not much direct financial gain from hacking the voting wallets for a stake pool. Stake pools are a proxy for users' representation in Decred, and this may present a juicy target for TLAs, banks, etc, who are not keen on their citizens or customers exercising their financial sovereignty and participating in Decred's voting process. This is the motivation for hosting the voting wallets on our own metal at various locations.
Your comment about complexity as a barrier the decentralization process is a good one. In the case of a stake pool, consider that the alternative is everyone having their own voting wallet, which could be 100s of VPSes/machines, so a stake pool, even with our more complex setup, substantially reduces complexity overall (100s of machines --> 4 physical machines + 3 VPSes). Several weeks from now, we expect the process for running a stake pool to be substantially easier to handle from an administration perspective. The current challenge is keeping the voting wallets in sync, e.g. web frontend drops link to wallet2 and needs to to have a few getnewaddress and importscript RPCs run against it to bring it back in sync. This process is manual at the moment and we're working to make it automated, a sort of simple journaling system (think filesystem journaling).
Also, this is only the case for pure voting pools. Shared resources stake pools (which could become a big deal later) will be another matter as they will be holding actual decred, and a VPS is not secure from the VPS provider or their agents. On the other hand, someone on a Huges Satalite link might find someone with a pool on a single server in the basement to be adequate for them. Far be it for us to dictate how much security is "needed."
I can host load balanced, auto scaling servers across multiple regions on AWS. (frontend) As for the voting wallets, an unlimited amount can be setup in different regions and availability zones. They can be monitored with something like Nagios and some custom scripts.
While I may not have the complete technical skills I certainly have the infrastructure available. I just sent my email explaining that my dev skill is mediocre, but I have a great deal of OpenStack and Dedicated resources -- also, Im willing to commit (preload) an account at my favorite datacenter with enough credit to fund a handful of enterprise servers for at least a year. ... if you can't tell.. I love cryptocurrency. It has had such a great positive effect on my life. I would simply like to increase my level of participation in supporting DECRED. GL! Looking forward to the good news
@frankbraun, @Fsig, @zzzzzz, @Shadowlance: Teams are great if you guys combine competencies. There are others also forming teams. A clear goal for the stake pools is geolocation diversity. So a good idea to think about is how we can get some up in different regions, and also how the timezones of different team members can be used to benefit a set up. The current thinking is that the project will introduce an RFP this week so that compensation is made available until fees can be integrated and stake pools become self-sustaining. This is reasonable given that the goal is to produce high quality stake pools, hosted and maintained by experienced people, that will require careful attention given the early stages of the software and the overall process.
Using AWS / Rackspace / Digitalocean / .... + docker / docker-compose + golang-libretto seems like a nice fit to me.
Is there anything to stop you running a pool by simply posting an address and people buying tickets with --ticketaddress="POOLADDRESS"? That would also let both the pool and the user vote, while not requiring a fancy front-end website or database, just a network of dcrwallets using that address?
The people who would be satisfied with that kind of user experience are probably solo-staking already.
That really wouldn't work well because the purchaser of the ticket would not retain the ability to also vote in the case the pool goes offline, disappears, etc. That is the reason the existing stake pool uses a 1-of-2 multisig p2sh address and hence is a "Dc..." address instead of a "Ds..." address.
Ah, right. I thought with ticketaddress the original wallet could still vote as well, obviously I was mistaken!
The code which defines the prefixes is in the chain parameters here. I've explained it elsewhere, but a Decred address is actually just a representation of a public key (which itself could be a script hash) along with a 2-byte prefix which identifies the network and type and a checksum suffix in order to detect improperly entered addresses. Consequently, as the params I linked show, you can always tell what type of address it is based on the 2-byte prefix. The first byte of the prefix identifies the network. This is why all mainnet addresses start with "D", testnet addresses start with "T", and simnet addresses start with "S". The second byte of the prefix identifies the type of address it is. The most common addresses used at the moment are secp256k1 pubkey hashes, which are identified by a lowercase "s". It represents a single public key and therefore only has a single associated private key which can be used to redeem it. The stake pool, however, uses a pay-to-script-hash address, which is identified by the second byte being a lowercase "c" (again that is shown in the linked params). The specific flavor of script it generates is a multi-signature 1-of-2, which is how it allows either the pool, or you, to vote. Both you and the stake pool have your own private keys and since the script only requires one signature of the possible two, that is how it allows delegation of voting rights to the pool without you giving up your voting rights completely.