1BTC Block finder bonus for next 10 blocks!

I'm glad to see things are going well.

I've been looking around at other pools as always but once again simplecoin.us seems to be the best for me.  The closest competitor in my opinion is mineco.in which annoyingly lacks a feature to donate a percentage of earnings to the pool.  rfcpool is a little further behind due to it's particularly stupid "Grace period for previous-block share submissions, resulting in LOW stale rates!".  Both have the transaction fee reward advantage over simplecoin.us though.

I'm hoping my 720 MH/s can net one of these promotional Bitcoins.

Setting up merged mining on the old pool server now.

Since many new users to the pool do not like the current estimate scheme (which was originally from user request/confusion months ago), I'd like to get an idea of what the current users would prefer.

So, would you prefer precise estimates that do not grow with difficulty, or do you prefer the way they are now?


My vote is for precise.

To be honest, I don't understand what the 'estimate' score actually measures.  For the PPLNS pool it would be nice to know how much I'd receive if a block were suddenly found.  Currently I do not have enough information to work this out.

If there's one thing I like about this pool it's the stats.  More stats are always welcome in my book.

It is 3 separate pools.

However, merged mining will be up very soon as will GeistGeld. I assume solidcoins will also be getting close.

It's unlikely that I will offer all the pool options for the new coins, I'm thinking prop for geistgeld, pplns & smpps for solidcoin and I'm not sure about merged.

Some thoughts on merged mining and PPLNS:

For merged mining I hope you are planning to essentially extend one or more of the existing pools rather than create a new pool.  Creating a new PPLNS merged mining pool would almost certainly kill the existing PPLNS pool which would mean a great loss for the simplecoin users who have submitted a great deal of the last difficulty/2 shares.

I would naturally want to use the same value of N for both Bitcoin and Namecoin for simplicity.  Is there a good reason why this would be unwise?

When merged mining hits, most Bitcoin users will be much more interested in the income bonus than in the namecoins and will naturally gravitate to pools which simply offer a 20% bonus to their BTC payout than to those that just give them the namecoins.  Personally I feel that a good pool should not try to also be an exchange but good links and instructions on how to trade earned namecoins into bitcoins will probably be very helpful.  Ideally, people should be able to mine and profit from namecoins without ever having to download the Namecoin client or create a Namecoin wallet (easily send coins straight from the pool to an exchange).

May I ask why with PPLNS you use such a large value of N?  I see that larger values of N can reduce variance (if the pool is big enough) but it also increases the risk (each share only attains it's full value if the pool survives for another N shares).  PPLNS (where N is independent of pool size) is a trapezoid scheme and I think it is prudent to keep the height of the trapezoid as low as possible.  Even values of N greater than 10`000 make me uneasy .

Yes, it is still experimental. There is also no long-polling support yet (so use cgminer).

I'm working with the creator to get things sorted. The blockchain is live though.


IF YOU ARE MINING ANY NEWLY ADDED COIN, BE SURE TO LOG OUT AND BACK IN!

Having thought about it a little more I see that it is very likely that you thought about this problem already and have stored Bitcoins from the first N shares in order to pay off the holders of the last N shares.  In this case no merging is necessary, the pool can simply be closed at any point and everyone will receive their fair reward.  I also see that this is the correct way to handle changes in N (i.e. changes in difficulty) for otherwise there would be a minor pool hopping problem.  Man, I've gone such a long time not appreciating this deeper elegance to PPLNS; my apologies for the previous post.  Indeed, this completely and perfectly solves all of my apprehension about large values of N and it seems the only factors are variance and payment lag.

There was I thinking there was 12.5 BTC worth of debt in the current PPLNS pool and was worried that that value had been mistakenly given out to the submitters of the first N shares!  *slaps forehead*

If the pool operator of a PPLNS pool also publishes all of the submitted shares (probably requiring a much higher share difficulty).  I can see now how it's fully possible to have a reward system which is completely fair to both user and pool operator, with no risk other than share variance and no required trust on either side!  Just this realisation has made my day.