rM3aAaKsZVKNUrgEs9NyDSwrnJcDjh9JbV

Confirming that I received my final payment. Thanks for putting forth the effort to close the pool fairly and get unpaid rewards out to as many people as possible. From the IRC logs, it seems like it was more work than ideal.

It isn't punitive to anyone. Over time, everyone will receive an equal payout corresponding to the number of submitted shares. The only effect of being an intermittent miner (such as a pool hopper) is that your payouts will vary more (sometimes less, sometimes more). For instance, if N is equal to the difficulty, a given share will be paid a number of times with the following probabilities:

• No payouts: 36.79%
• 1 payout: 36.79%
• 2 payouts: 18.39%
• 3 payouts: 6.13%
• 4 payouts: 1.53%
• 5 payouts: 0.31%

The probability of six or more payouts is there, but shrinking very quickly. The weighted average of the samples I gave is 0.9963 payouts per share. If I included 6 payouts and more, the average would be 1 payout per share. No matter what, on average, you will receive the same payout for your work on a PPLNS pool as you will at a PPS pool (assuming equal fees).

Yes, your shares may suddenly become worthless if more than N shares pass by without a block being found, but there is no way to predict when this will happen, and 63% of the time a share will be paid at least once.

In the case of the short bursts of activity, you will still receive your equitable share for the comparatively few shares you submitted, but because of the risk of not being paid at all, again, the variance will be higher. In those 31 out of 10000 instances when your short burst of work is paid out five times, you'll be making back what you "lost". Of course, this is all on average, and if you're looking at periods as short as a week or three, you may not feel you're getting your fair share. If variance bothers you, use a PPS pool. However, there remains no long-term mathematical reason to avoid PPLNS as a backup.

The expected value of a share under PPLNS is exactly the same as the expected value of a share under *PPS (ignoring the possibility of the collapsing SMPPS pool for the moment). With PPLNS there will be more variance in what each share actually gets paid (sometimes nothing, sometimes once, sometimes several times), but on average, the payout will be the same. There's no good reason to avoid using a PPLNS pool as a failover unless you really don't like any sort of variance.

I've been running my local bitcoind with the getblockbycount patch just fine. The patch has to be somewhat manually applied because there are conflicts since the last time that branch was rebased or merged. Someone should either update that branch or put an updated version somewhere else. Or even better, get the patch merged into bitcoin.

psy: In what experience I had, the biggest barrier is doing the initial load of the blockchain. It was fairly I/O intensive and wrought havoc with my VPS. I eventually had to give up (as it would have taken several days to finish), and run it instead on my local machine. However, the particular host machine my VPS is on has had a history of high I/O load from other users, so it's possible it might work better elsewhere.

At this point, I am neither using poclbm-autohop or poclbm at all, so this program is likely to slowly enter a state of bit rot. I will continue to update the API as long as it is feasible to do so, but since pident is seemingly no longer maintained, that may not be as long as we think.

I still find the current methodology interesting, and if proportional pools continue to propagate, I would like to reimagine the implementation. Most likely, I would write a custom (and open source) program to generate the API automatically without reliance on external software like pident, and design it to be non-resource intensive, to allow it to be deployed by multiple people if necessary. The biggest problem is determining what kind of resources are needed to store block information, and whether or not to implement some kind of scoring algorithm. (It's worth investigating, in any case.)

The second component would be a new miner. At this point, it's likely I would attempt to modify cgminer to access the API and use its data. I did a cursory look into what would be needed a couple of months ago, but I suspect cgminer has changed slightly since then. In any case, it's dubious that I'll have the time to get any of this done anytime soon.

The API is currently in the process of being updated. The scripts are currently catching up with the last week's worth of blocks, but it should be caught up shortly.

I think BitMinter was hopped, so I'll make the change whenever I get a chance. Thanks for letting me know, because it can be hard to keep track of all the pools myself.

Congratulations on switching to a fair reward system. I'll make sure to leave bitminter in as an option for people to use as their fair backup.

The API will cease updating sometime in the next hour or two. If you wish to continue hopping effectively, you should probably convert to an alternate solution such as bithopper or cherrypicking at this time. Otherwise, your miner will likely continue to mine at a fair pool such as mineco.in, eligius, or arsbitcoin (if you have one configured). This isn't a bad thing, but you won't be maximizing your reward.

I expect the API to begin updating again on either the 29th or 30th, or sometime before that if I manage to come up with an alternate solution (but I wouldn't count on it).

Looks like the update process froze again. Sometimes, the pident script that checks which pools have solved which blocks never finishes, and since I've implemented some locking, so two updates never run simultaneously, it gets jammed up. I should probably set up a watchdog at some point, or at least figure out why updatepools doesn't ever quit sometimes.

Anyway, the situation is fixed, and updates should be coming in the next few minutes as pident catches up with the block chain.

However, please note, once again, that there will be no updates for about 8-9 days starting in about 28 hours. I advise users to investigate other options like bithopper or cherrypicking for that duration. I thought about putting together some kind of limited update script, but collecting all the data from the pools might be more than I can churn out in the next 24 hours (especially since my time is limited).

At some point, I'm going to have to find a way to either modify pident or write a replacement that isn't so hard on disk I/O so I can put it on a VPS. Relying on my local machine is too hit or miss.

The API is currently not being updated due to a problem with my bitcoind. I will attempt to fix it as soon as I can, but it may be a few hours. Until then, miners will mine at fair pools most likely.

UPDATE: API was fixed a few hours later. Of course, remember once again that it will not update for approximately a week in late September.

This is sort of what I've attempted to do with poclbm-autohop (there's a thread about it in the mining software forum). The only thing that's ultimately pulled directly from the pools is the list of solved blocks. The biggest problem is that it relies on an API I compute on my own machine and update online when it changes. This makes me (and my computers) a major point of failure.

Actually, for each block that could possibly be each pool's last block, it calculates the expected efficiency if that block, and then does a weighted average of the efficiencies over all possibilities for the latest block.

Results from BTC Guild suggest that it works relatively effectively, but collecting enough data to be sure (or automating the data collection) is more work than I have yet wanted to do. Also, the system would have to be modified to handle hopping a pool that doesn't report any of its blocks.

In short: stat delays make hopping slightly more difficult, but they won't eliminate the problem, especially as techniques such as this become more common in the various hopping softwares.

I can't think of any reason PPLNS would be more dangerous than any other system. Assuming you can trust the operator, it is both hopping-proof and much more resilient to long periods of bad luck than any of the PPS variants.

If you can't trust the pool operator, then all systems have potential for abuse.


I had avoided adding bitcoinpool completely because of its Draconian measures designed to fight pool hoppers (rather than changing reward systems). Of course, as hopping becomes more prevalent, you can expect more pools to go down this road. Hopefully, they'll have to become so awful that users won't want anything to do with them, but I don't have high hopes in that regard. Users seem willing to tolerate a lot of abuse.

As long as it's relatively accurate up until the crossover point (when it drops below 1.0) it should be fine for my purposes.

Based on available data, usually things like the current number of shares (but in slush's case, also the time since the last block and the hash rate, I believe), the expected value of a share, relative to PPS. I prefer a mathematical function to a table. For instance, the relevant function for proportional pools is equal to 1.0 at ~0.4348.

Though, in order to add slush to this program, at least, I'd have to figure out how to calculate the utility of a given share. It should be possible once I've done the relevant analysis, but I don't exactly have the motivation to do such a thing at the moment.

As a second point, I'm worried that the list of pools I'm operating with is languishing a bit. It seems NoFeeMining changed to RSMPPS at some point, so it's been changed to a fair pool. Have there been any other proportional pools started? I hope we're past that point, given how easy it is to hop them. I'm unsure about adding any additional fair pools, as I already support several. In any case, they'd have to be added to pident first.

For anyone who wasn't around on IRC:

pushpool crashed at some point. BurningToad was able to fix it remotely, and things should be looking good at the moment.

Looks like the update process locked itself up ~18 hours ago. It should be catching up now, unless there's a bigger problem, which I'll find out shortly, I assume. Consider this a preview of how things will look when updates are suspended for ~8 days in late September.

As it turns out, the donation percentage code never actually correctly read the donation percentage from the configuration file. This has been fixed.

In other news, there will be approximately a one week period in late September where the API will not be updated. As a result, anyone using this miner will most likely only mine at fair pools for that week, rather than hop.

The ultimate goal, however, should be to somehow improve the whole process so that it doesn't rely on a third-party API. However, the reliance on pident makes this quite difficult. I have little time for bitcoin at the moment, so I'm probably not going to come up with anything myself anytime soon.

A short period where the buffer is negative will likely not be detrimental. However, if the buffer at some point meanders quite negative, rational miners will no doubt begin to trickle away, as at that point, the chance of receiving full pay for your shares anytime in the near future is rather small. I expect this wouldn't become significant until the buffer went below -1000. But that's just a guessing game.