This is a nice idea on first glance but unfortunately totally defeatable.

If the share was solved in the past then it will be in the blockchain. Thus it can be seen that the miner is being tested and he will send it back regardless. A hash table lookup of 140,000 blocks would be pretty trivial.

You would have to find a winning share yourself and NOT make a block out of it, then keep that getwork to one side for future miner tests. And then hope that withholders don't collude and inform each other about your getwork test and add it to their database of ones to always submit back - then you'd need to generate another

As of now, rfcpool distributes the block fees in each generated block to our miners.

Additionally, PPLNS N has been changed to difficulty*1. This makes our per-share value comparable to pure PPS pools (but remember, we are not pure PPS).

First block has been confirmed and first payments for it sent out - we're officially back in business

Still looking for opinions on what to set N to. We now have diff*0.5 shares since relaunch so old shares are rolling out of the payment window. Current view is to set it to diff*2 once we reach that figure, then probably leave it for the time being. If you would hate this, shout here.

Nice to have you back ChrisLandin

AnnihilaT, yeah I think we're still up in the air about that. Graet was lookng for more coders, I was at a dead end at the time so agreed, but then a day or two later my arm was bent far enough by old rfc regulars to reopen it.

Clearly this leaves us in a bit of an ambiguous situation - it's a slight conflict of interest to work on two pools at once, however me and Graet do get on well so if he's just after a bit of extra sysadmin help from time to time then I'm still happy to fulfill that, but the majority of my time (besides going on real, actual paying contract coding work I do for a living) will be on rfcpool.

For clarity:

rfcpool just found a block after 688718 shares (excluding stales, which are obviously worthless).

N was set to diff*0.5 (902850) so obviously if you do the maths you'll see that our total payout for that block would have been under 50 BTC (clearly we weren't going to include blocks 10 and below in the calculations, they were rewarded under Prop/PPS separately)

For this reason, N was set to 688718 as a one-off, meaning that the full 50 BTC was paid out. If you were watching your estimated reward in our stats, you'll see a big jump in the final rewards table for this block now: https://www.rfcpool.com/stats/block/11

These rewards will be added to your balances shortly, I'm just checking scripts over first.

N has been set back to diff*0.5 now. If you check your estimate reward in My Account, you can see that the next payout, at the moment, will include shares from block 11 and the new ongoing one.

Hope this answers any pending questions.

No, it shouldn't matter - N being at 0.5 right now isn't set in stone, it's just to get us going; I didn't want N too high at first because it would then take ages for the initial reward estimates to ramp up.

Using H instead will just avoid having to tweak N when the pool hashrate varies.

See https://en.bitcoin.it/wiki/Confirmation

Coins are not released into a wallet by a generation for 120 blocks. Nobody is trying to screw you over here

Yep, lessons learnt, new reward system, backend scripts being tidied up, etc.

Main issue at the moment is what to set the 'N' in PPLNS to. It's 0.5 but subject to change, considering PPLNH with a 48 hour H actually. Maybe I should do a poll for this?

Yeah N is still up for discussion and tweaking. Might actually go PPLNH instead with an H of 48 hours. But offtopic for here.

What? So now a http proxy server between two local ports (possibly on the same machine, maybe over a LAN, I don't know the details of your setup) is remarkable that it works?

Many systems administrators would laugh at you for that comment - it's bread and butter stuff, and should work absolutely flawlessly.

Are you aware that some of the big pools are proxying *ALL* their requests from the frontend to backend daemons (over, usually, nginx)? Do you see them saying it's remarkable it works?

Try harder and stop spreading this crap. Miners don't have to accept this level of FUD.

It's sorted. After calming down somewhat and recreating the wallet from the private keys, the dead transactions disappeared and I was able to send the BTC again, and this time the network has accepted it.

Everyone should have their earnings now, without exception.

Well, apparently sending lots of transactions at once with no fee causes some of them to be lost into the void forever, being trapped by some internal flood detection.

This morning quite a lot of them were stuck at 0 confirmations, and the money appears not to be in our account or yours - nice one bitcoin!

So I've resent them, this time using a fee of 0.005 and sendmany - bitcoind reported a transaction id of c8ec198e8ba4a99eee14b370baddd1467dae475c268d2ecc15bd07658eacb4cf for these. As of yet it has not appeared on blockexplorer or in the unconfirmed transactions list.

Frankly if that doesn't work, then you'll just have to pop over to Solihull in the UK and collect your earnings in cash, because I just don't trust any more money to this system. Good money is now disappearing after bad and I'm done with it.

I'll publish a dump of our listtransactions if anyone wants, I don't think there are any privacy issues with it - all the information is freely available anyway?

Sorry about the delay, was away in the peak district for a few days with no mobile signal and no Internet. Doing the balance payouts in the next few hours.

Yes, the final 4 minute block will be paid out, of course

Block #9 is already in your confirmed balance - block #10, ironically found 4 minutes after I reset the round to remove PPS, should be in your unconfirmed.

Also sigh, I think everyone got paid twice for block 9, enjoy your windfall

Did you read mine? I said if, it was a question.

Why do miners take so much crap like this and lap it up? As a pool owner I'm horrified. Here's the way I think it should be done, using my pool as an example:

I currently offer Prop and PPS, but I want to remove PPS until we grow (a total 180 on my previous  position but thats another story for another day). It would be downright rude to swap everyone from PPS to Prop mid-round, not to mention totally screw up all the payments.

So basically there's two solutions, reset everyone and pay them, or reset everyone and don't. I will be doing the former later today. MaGNeT, if you had mined Prop for 8 days without payment, and then it got reset, do you think you'd be singing the same song?

Ok, abrupt change on policy I'm afraid. We are dropping PPS from the end of this round; the maths doesn't really add up for us and we've been haemorrhaging BTC for the last few blocks now.
Having to watch the pool constantly and keep on topping up it's balance (we're about 50BTC down) is getting old. And I have real work to do, which isn't getting done

All PPS users will be moved over to Proportional when the block is found so if you don't want that, you will need to find another pool.

Not at all. There's 3 people behind rfcpool and all of us are systems administrators and coders, so we know a thing or two about running a service.

I shan't name any names but it's rather concerning seeing the quality of some of the pools popping up recently, with admins who use a prebuilt frontend having no idea how it works, and asking for help on how to build/run pushpool. Seriously, if you're going to run a pool, you should be able to figure this stuff out on your own. You'll run into far greater problems with pushpool once you grow than how to chuffin' compile it.

So yeah, Jack, you're right to be concerned, every new pool recently including ours has to prove themselves. I however, will let the pool speak for itself and don't feel the need to try and force it to grow by offering rewards and bonuses, or pimping its 100Mb superduper fibre-optic line (lol?) like it's something special that nobody else has.

Rant over I think. :p

I think since launch near the end of June we've had under an hour of downtime in total. That's actually a pretty bad record for me but I'll put it down to growing pains.
We're still on a single server (the pool size doesn't warrant anything more) but there's decent redundancy within it, I can restart one of our multiple pushpools for instance and you wouldn't even notice.
Hardware failure would be our big achilles heel right now but I'll invest in duplicate servers once the pool earns itself some money (currently we're 30BTC down thanks to an invalid).

They were mostly hoppers I'm afraid We see an influx of about 130GH/s after a block at the moment.

We do offer PPS though so if you don't want your payments to be affected by them, there's the option.

Awesome, if we're quoting hopping MH/s figures I can change my pool from 25 to 200GH/s!