That's because p2pool usually has a very fast target rate for the share chain and that creates more stales. However, be sure to submit the stale shares because they can still be valid blocks that will pay the pool.

Well then perhaps I'm using terms wrong. By variance I was referring to the # of shares on the share chain (how often he'll get paid being the concern, not the amount). At his speed he'll rarely find a share, so often blocks will pay out with no payment to him at all. As opposed to a normal pool with a tiny but steady stream of credit.

I thought the rate at which you receive payments was normally what people refer to as "variance" when we're discussing p2pool, and the issue with smaller miners on p2pool is the amount of time you'll have 0 shares when blocks are found, resulting in no payment at all.

Obviously the absolute amount of coins will be larger with larger hash rates.

Haha I'm dense. I'm so used to running public nodes it didn't even occur to be a normal miner running their own p2pool will have the time to share on there. Doh!

What I was thinking at the time was how multiple miners on the same public node can't see their personal "time to share" unless the interface breaks that out and there is a patch to add a couple of required API calls to make that happen.

It didn't come up on the one I purchased. We also have no VAT/etc to worry about in US.

Some altcoin p2pool interfaces show a "time to share" but no BTC ones that I know of. You can use normal calculators though to put in your hash rate and the share difficulty to get an idea on how bad the variance is and if you are willing to stomach it. I have some smaller miners in my closest I've not touched in ages that are still happily hashing away with a raspberry Pi. I just check now and then they are still hashing and otherwise just ignore them.

About 500K on average. Here's a 24 hour graph.

http://vtc-us-east.royalminingco.com/p2pool_share_history/diff_history.png

Oh come on, don't suggest people use the 2 largest pools in the world.

If for whatever reason you don't use p2pool, check out bitparking.com. It's a quality smaller pool that could use more hash power and supports merge mining.

The variance on 2GH on p2pool will, sadly, be massive. You could farm from sha256 alt coins though. Or else you might want to use a normal pool. (The proxy pool project I want to port to sha256 but haven't had time.)

For $650 you could buy an Antminer S1.

What's amusing is the posts and explanations on the heavycoin thread explaining why GPU mining the coin is impossible.

As prices keep dropping I feel so tempted to buy a 2nd one, but at the same time, I want to save my BTC to buy an S2 once they are available. Aiiiiiiiieeeeeeeee.

I can't say for sure but you likely need some minimum amount of hashing history before they populate.

Stales have no effect on network hash power in terms of generating coins because stale shares that meet the block target are submitted to the coin daemon. If it is accepted, then the block pays out to the network even if it was a stale share for the share chain.


This wouldn't be healthy for the network. All shares should have the same chance of being stale. (Well, some nodes are more efficient than others, but it isn't because of the contents of the share.)

Miners using higher diff targets to help out smaller miners aren't hurt more by stales than anyone else. Yes when they have a stale share it is a larger loss than a smaller share would have been, but the smaller shares they are finding, the more stale shares they will have because it's all a %.

If you have a target of 1000 and a 1% stale rate, each stale share loses you 1000 diff 1 shares worth of work.

If you instead set target to /1 and have a 1% stale rate, then out of every 1000 diff 1 shares worth of work you lose 10 shares to stale and have 990 accepted.

In other words:

1000 per share * 100 shares = 100,000 shares of diff 1 work * 1% = 1000 diff 1 work (1 share) lost as stale.
1 per share * 100,000 shares = 100,000 shares of diff 1 work * 1% = 1000 diff 1 work (1000 shares) lost as stale

All in averages, of course. Total credit lost exactly the same. No matter what target you set, you'll lose stale % amount of it. The target will only change the variance of the stale cost.

My understanding was the refunds were only partial and based on the amount of sales that completed since there were no funds left over to do further refunds with? Keep in mind burnin ordered large quantities of parts and supplies that he could not return in order to full all of these orders, many of which were never completed because people didn't send chips to him to complete their order. Which also isn't burnin's problem, it was the buyer's responsibility to get the chips delivered to him for assembly.

Slush's support thread is at

https://bitcointalk.org/index.php?topic=1976.0

which is linked off of slush's front page.

I wouldn't suggest you rent a server just to run it when you can use other people's public nodes instead. Some were suggested to you in the other p2pool thread where you asked the same question.

Install p2pool and point your miner at it. Or use one of the public nodes if you don't want to run it yourself, but running your own copy is best.

Are those the ones that can only accept DIFF 1 work? If so, add /1 after your payment address, but you'll have lots of network traffic to the pool. Best to run a local stratum proxy if that's possible, or a local p2pool node on your own computer.

Yes I submitted a patch to fix that.

https://github.com/forrestv/p2pool/pull/185