Moo. I would be willing to rework the whole pool to have something that can perform on a high-end VPS. Surely pools will stop going under if we can cut the operating costs to under $30/mo?

My performance target would be a pool that can handle, on a $30/mo VPS, 100 miners mining at total of 100KH/s while checking every share (with AES support), or 25% of the shares (without AES support). Other features would include rig stats, and multiple payout schemes (proportional, slush, PPLNS, and PPS).

Let's apply some simple maths to see what is the pool fee that would cover the operator's expenses at that level: At current diff, this pool will find 41 blocks in a month, and have around $4309 total income.

To cover $30 server costs, operator would have to charge 0.6% fee. That means even small pools will be profitable.

The pool can currently perform easily on a high-end VPS, by and large, the bulk of the running time is the Monero Daemon, not the pool itself.

I've rebuilt the majority of the pool at this point to support this, but it required a pretty heavy rewrite to do so. I'm not against OSS'ing this code under the right circumstances, but I would not say that the code I've written is designed to be run lightly. The ram usage of the main database can be extremely intensive, and the block unlocking daemons are quite heavy due to the addition of PPLNS.

Also, the calculation for the fees does not currently include the price for transactions done from the pool, which is a growing cost in the post Ring-CT world.

After a bit of discussion with a couple of involved parties, I'm currently reworking the pool to run on LMDB rather than InfluxDB and will be open-sourcing it once complete. It's the hope of those involved in this decision that we'll see pools run more readily and people will be more interested in running pools on their own, but we'll see! I'll keep this thread updated with status information in relation to this.

InfluxDB simply has too many issues at this point in time with queries not related directly to time, so it's not practical for the usage of a pool unfortunately. It's my hope that LMDB will fix a lot of this, and remove the heavy dependencies.

So I figured I'd throw this out there, with all the changes I've done at this time, I'm comfortable saying that I have a fairly mobile, agile pool source that supports PPS, PPLNS, Solo mining, Backed by LMDB for share storage and processing. MySQL for transaction (Payment) data. This is running on a small variety of servers at the moment, but by and large, could be run on <40$ VPS' without too much of an issue, assuming they have SSDs.

Per-miner stats are complete, no-frontend for them yet, Mesh00 is working on that, and is doing a fantastic job with it, as he's redone: https://xmrpool.net, which is our running reference copy of the code. We've done tests out to 3-4 Mh/s on a E3-1270 w/ 16Gb of ram (2gb used) for our leaf/pool code, the majority of that pain is from the Monero Daemon, as the system runs at .5 load while verifying shares.

Per-miner notifications with Email is complete, integration with MailGun (Free for low volume, so ideal), means easy integration of other e-mail notifications. Custom payout thresholds are on the todo list.

I'm currently torn between FFS'ing and simply open-sourcing the pool (Both routes lead to this, at least eventually). Ideally, I'd lean towards FFS as I would like to implement more features over time at the request of the community, it's a fairly fun little project, and the Trunk/Leaf design means that pools have impressive flexibility to deploy remote nodes to any variety of locations, while still handling shares in a safe, sane manner.

Xmrpool.net uses this all as reference code, and serves as a living testbed for this work.