I don't overclock so I get about .03 day. My stats are here:

http://eligius.st/~wizkid057/newstats/userstats.php/17PHEZaiJqARt7GkBC8MLRijUDSgAgpH9P

The gaps are when I mine alt coins. But I've mostly been doing BTC all this week.

Buy right before a price drop and they'll give you a coupon for the price drop you can use on your next order.

Run your wallet once with the -rescan command line option.

I remember gmaxwell reporting the Cointerra machines work wonderfully with p2pool. Wish more CT owners would install some nodes and get with the p2pool program.

I really wish some big farms would run p2pool. p2pool needs the hash rate.

Anyone having the issue with mazacoind taking forever to reply to RPC commands, a fix was provided here: http://cryptominers.freeforums.org/post232.html#p232

Sorry for rocking the boat. I'd asked rav3n to review and add to his repo if he wanted, since I use it for other coins already and figured it'd be convenient if he dropped it into the github.

Has anyone had trouble with mazacoind taking a long time to respond? If I just run "./mazacoind getinfo" it takes 16 seconds. The blockchain is downloaded and current, server load is fine, other coins returning getinfo in < .1 seconds. Not sure where to even start to try and figure this out. Nothing unusual in the .mazacoin/debug.log file.

If I tail -f the debug.log file, the ThreadRPCServer method=getinfo doesn't appear until after the long delay either. So it might just be in the client side.

Edit: Actually, the instant I do the getinfo command some CBlock stuff appears in the log file instantly. Then ~16 seconds late some more, the method line, and the result is available. Watching top, mazacoind maxes out the CPU until the response is provided.

Edit: Someone provided a fix here that worked great: http://cryptominers.freeforums.org/post232.html#p232

What's the max number of cards for nVidia drivers? With the hash/power ratio of Maxwell, it'd be interesting to try this if nVidia allows > 8.

Will the CUDA 6 release have any impact on mining?

It just depends on your hash power and the difficulty of the coin you are mining. p2pool payments have more variance than traditional pools.

You might try using separate addresses to try and isolate the problem. If you have two 180GH miners and they are both pointing to the same node with the same address, you should see a 360GH hash rate being reported.

They go to the coind wallet unfortunately. There's no easy way to adjust that on the fly since the wallets themselves don't support it.

One could perhaps hack the wallet's API call for getblocktemplate to take an extra "payment address" parameter, and block that into the template returned. This way different miners could get different merged work.

0 in peers is fine, you have 7 out so you are connected. You only get paid if you find shares for the share chain and


Is not pretty. It will take you on average 6 days to find a share. That share will be worth enough to cover 6 days of earnings, except the pool also needs to find a block while your share is active.

Some miners with 180GH of hash power don't like using p2pool because of the variance. Using it with 4GH... you can do it, but you might wait weeks at a time without a payment if you have bad luck.

Ahh ok. Yes it might seem like they get more when they have shares in the share chain on the Payouts list, but the "hidden" information there is that the tiny miners often will have 0 shares in the share chain. Small miners can't be paid all of the time because they would make more than they are supposed to. Since there is a minimum difficulty for shares, the only way for people to get correct average earnings if they are below that difficulty is by having a payment window that isn't "all of the time". Of course, when getting paid, the small miner might look like he's getting more. But it's only because his payment window is smaller than the bigger miner.

People shouldn't confuse the payout amount on the share chain at any given time with a projected average daily earnings or anything like that...

I think that sounds awesome. The thing is the disk space for the share chain isn't that big of a deal, it uses no space really compared to the bitcoind blockchain itself. And older shares once expired don't need to be saved forever. If the sharechain can work more similar to a normal PPLNS share database at centralized pools, that'd be a big win for smaller miners. (Some way to accumulate tiny shares without paying them until they exceed the dust level might be useful, but prone to abuse if someone tries to flood the sharechain with changing addresses just to bloat it.)

One option is that all stales still get passed around like valid blocks, and payments are based on all valid + stale blocks. It isn't like bitcoin where we actually need a single chain with a record of transactions. We're only using the chain's POW so we don't have to trust clients on how much work they are reporting.

Another thought on the dust issue for small miners with tiny shares is when they are served work, that work include the prior shares value that was too low to pay. That is, a normal miner finds shares A B and C. When calculating payouts, that miner is going to be paid A+B+C until those shares start to expire off the chain. A small miner finds share A that is below dust level. They don't appear in the Payouts list. However, when serving work to miner A, they are served a share to work on that includes the diff value from share A. When share B is accepted, share A is invalidated and share B has the value of A + B's new work. If B is > DUST, it goes into Payouts list. If not, then when small miner finds C, C will include B and B is invalidated.

The thought for doing DUST this way is the tiny miner can keep building a balance without storing every tiny share on the chain, and their dust won't expire off the chain before it can grow above the payment threshold since the share's age resets on each new share found. If the miner is so small they can't find even a tiny share consistently within the PPLNS window, they they probably need to mine something else. This might be more appropriate for a pay-once PPLNS structure though and not the traditional PPLNS window p2pool uses now.

(BTW, I've never looked, but p2pool needs to store the block (share chain?) difficulty when work is served so that can be logged on the share chain with the share, and payments based on the diff of work done vs diff of the block, not just the diff of the work done. Otherwise people get unfair rewards around diff changes and the pool is hoppable.)

Not to change the node fee payment address. -a sets that address, as jedimstr said above.

If the 6MH miner on royalminingco with address VdRuGS happens to read this, one of your rigs is mining with the wrong address. It looks like you made two typos in the address (Z vs X, 8 vs B) so the payment address on that rig is invalid.

You can try -Q 0.

How about vertcoin? It has an N factor of 11 (2048) I believe for couple more years.