If you want something easy to use, try bitminter.com - signup is quick and we have a custom miner you can launch by clicking a button on the website. It doesn't get much simpler than that.

Live stats for current NMC round is not displaying correctly. Working on that now.


Yes, once the shares are out of the last 10 shifts, they won't get paid more. So if we didn't create any blocks while they were in the last 10 shifts, they were a loss.

GPUmax is fun to play with, but the shares are priced very very high, and you'll most likely lose money buying them.

BitMinter only creates its own blocks. Shares are not sent anywhere else. Bitcoins + merged mining of namecoins. The word "BitMinter" is included in the coinbase of the bitcoin blocks.

I think transparency is important. If your pool op is doing something secret with your shares, it's probably because he thinks you wouldn't want to mine there if you knew what he was doing. And he might be right.

Yeah, it's because of how they do long polling. I guess they get 1% to 2% stales or so.

Stales come at the block change, in a pile. If there is a new shift just starting at the time of the block change, then the new shift will contain a lot of stales in the beginning. After a few minutes the stale percentage should look much better again.

I'm considering whether I should disable extrapolation of stales. It is probably more accurate to only use actual stale numbers and not update them before a new number is received from the server. Not only does it look strange the stales slowly creeping up even without block changes, but the extrapolation often seems very inaccurate too.

Or try BitMinter. Also zero fees. One click on the webpage to start the miner, or use your another miner if you prefer.

Hmm, yeah. But if I set the max to the true max for the new server, the current speed will look so puny. Guess I need to make it dynamic.

Glad you like it Supporting other pools is on the list, but I'm not sure when I get around to it. People keep giving me so many great ideas that the TODO list by now is probably several years long. Multi pool support is not at the bottom of that list, though, but I do have some more important things to do first.


As was already said it's GPUmax. It's very nice that people run some GPUmax hashes in the pool. Just be aware that you have to pay more for those hashes than their expected value. That means there's a smaller chance of making a profit, than ending up with a loss. It's a bit like gambling in a casino. It can be fun, but don't expect to still have your money when you leave.

When GPUmax gets a little bigger maybe I can rent 1000 GH/s for a while to see how it affects the server load. When the pool was doing 320 GH/s I could barely see any load. Gotta love the new server!

Maybe now you can write one.

Yeah, like you say, kano, you basically have to read the source code, because the documentation is a bit slim.

But if you thought this was bad, you should try implementing merged mining.

Lately we had a lot of bad luck, and I estimate we lost about 10% of users and workers, and about 8% of hash power. This always happens when we hit a streak of bad luck, and the variance has always been a constant impediment to the growth of the pool.

I'm thinking about two ideas to solve this, and I'd like to discuss them here.

The first idea is to join p2pool. I don't really know much about it, but I see what I thought was a 0.5% fee is (at least these days) an optional 0.5% donation. Turning the donation off I could hook bitminter up to p2pool and still keep this pool zero fee.

Thoughts? Possible issues?

Can we still build our own blocks as we see fit and put things like BIP16 votes in it? Will we get orphaned shares in the share chain, the same way bitcoin blocks are orphaned (invalid)? I guess it doesn't matter as this should happen equally for all p2pool users.

I have many ideas for building my own stuff for cooperation between pools. But if p2pool can do the job, it saves time I can spend on other features instead.

The other idea I'm considering is a "share market" where you can sell and buy shares (proofs of work). Yes, it would be possible to make it similar to GPUmax so you can sell hash power to other pools. But I'm thinking firstly about shares within BitMinter. If you are worried about variance you can sell your shares at a price below their expected value and get a steady income. Like mining PPS with a couple percent fee. Other users who don't worry as much about variance can buy those shares. The buyer is the one that gets a score in the shifts and gets paid when a block is generated. As long as the share price is below the expected value of a share, the buyer is likely to make a profit over time. In the middle of that I can take a fee on share sales to get some income for the pool.

Seems a nice idea in theory. However, variance could make it too risky to buy shares. This is basically what operators of PPS pools do, and sometimes their results leave a lot to be desired.

Any thoughts?


Way to go, bitcoin

DeathAndTaxes - very nice ideas on block stats. Added to my list.

The duplicate proof of work message is new. Only recently did I add support for reject-reason to the server. And also, only recent versions of cgminer supports reject-reason. Probably same with other miners. BitMinter client will support it very soon.

About block solving rewards, it is on my list, so it's coming sometime. Kain, I think the transaction fees going to the solver is today not enough, and in the future too much. But triggering block rewards at a certain CDF level is probably a good idea. Once donations are working I think a solution could be a "block rewards" cause you could donate to. The collected coins would be paid out to the user creating the next high CDF block. Either pay out the whole block rewards pot at X CDF. Or pay out a share of the pot, proportional to how high the CDF is.

Another thought is that it may be good to always have a block reward even for fast blocks. A block reward makes a block withholding attack more expensive.


You may have to reinstall AMD drivers after installing the second card, and you may have to reboot after that. If that still doesn't fix it, maybe you need to use driver sweeper and then reinstall AMD drivers. When I added a 5970 to my system that already had a 6990 it got pretty messed up at first.


Yes, still zero fees and paying out the transaction fees.

I haven't tried hashkill, but you should be able to get any miner to work by connecting to mint.bitminter.com port 8332 (use port 80 if a firewall prevents you from using 8332). As username put USERNAME_WORKERNAME where those are your username and one of your worker names on BitMinter. As password you use that worker's password.


Yay!  Nice low stale stats you got there!


He's got the powaaaaah!

In other, totally unrelated, news: buying GPUmax shares for BitMinter seems to work fine now. Just be careful when you enter pool information that you use http://mint.bitminter.com:8332. If you don't include the 8332 port number it will attempt to run through port 80. Port 80 mining is slower and more prone to timeouts and other issues. Only use it when you have firewall problems, not to channel massive hash rates from GPUmax.

Yep, that looks correct.

Hmm. It's very dangerous to give people something for free, and then later make it non-free. But yeah, if it is made into a "free during beta test!" kind of thing from the start, it might work.

I think the main issue with making the web service is how to detect that a miner is dead. The current hash rate shown on the web site is very unreliable for slow workers. It can be sometimes 0, sometimes 150. I guess I either have to find a solution for this, or say that this service does not work for slow workers.

Well, there's two things to consider. Higher N is nice because it spreads income out over more shares (proofs of work), so the payout for a share is more stable. But a lower N is also nice because you get all the pay for a given share quickly. I think paying N shares where N is the same as the difficulty is a good balance. Perhaps when the pool is larger we can can go 2 x N.

Currently it takes about 15 hours before work you did is no longer eligible for more pay. And after those 15 hours, if you got a block towards the end of that period, you have to wait another 20 hours for the last block to be confirmed. Worst case you wait 35 hours from doing the work to getting paid. In the future you can donate and not have to wait those 20 hours for confirmation, but your work would still be getting pay for ~15 hours. Probably best not to add to that.


Thanks, Becks


Yes, the current web service API is just general pool-wide info.

Here's what I'm thinking about this:

• 1. First implement donations
• 2. Personal miner stats web service, make it a cheap perk you buy with donations. Now you can use one of the third party offerings for detecting idle/dead miners. I may have to contact the authors of some mobile apps etc to get the pool working with them.
• 3. A general message system with events triggering messages and channels delivering them
• 4. Email as the first type of messaging channel
• 5. Idle/dead miner as the first type of message event
• 6. Other channels and events...Block built, payment sent, etc.

My own workers had connection problems today 11:57-12:07 UTC and 14:21-14:28 UTC. Looks like that coincides with your drop in stats on BitMinter. I hope that's not how things are going to be with the new data center.

17 minutes shouldn't affect your stats that much though. Perhaps the miner took a while to move back from the backup pool?


Yep, it's on the famous TODO list.

No, the GUI doesn't really help make more bitcoins. Still, a good user experience and less hassle is worth something to many people.

I switched to v1.2.2 of the back end a moment ago.

What's new:

• Faster reaction to block changes (detect blocks from other pools faster + initiate long poll response faster)
• Use X-Reject-Reason to tell the miner why its proof of work was rejected. Support for this coming in the next release of the BitMinter client which will log the messages. Support by other miners is listed here: https://en.bitcoin.it/wiki/Getwork_support
• Improved logging. There is a bug causing the back end to freeze up for 2-3 seconds. Seems to happen about once per day. Hopefully this will help track it down.

Look at http://en.wikipedia.org/wiki/SHA-2, under pre-processing. You will see that running a full sha-256 implementation will add some data to your input. It will add that, hash 2 chunks, and give you the wrong result. Unless you can force your sha-256 implementation to only hash one chunk of data and nothing more, you'll have to write a function that will.

Also you should not take the reverse of the string. For each group of 4 bytes you should reverse the order of the bytes. So "0102030405060708" becomes (0x04030201, 0x08070605, ...). If you are going to send the result as part of a getwork response then you will have to do the same on output. You will find this little-endian mess all over bitcoin code and APIs, sometimes mixed with big-endian to make sure you get confused.

If midstate() is a function that takes an array of integers and returns an array of integers:


Note the Integer.reverseBytes() on both input and output to reverse the order of the bytes within each integer.

I never tried BAMT, but perhaps the password should be in the URL?


where PASS is the password for the box2 worker.

Say what?

With PPLNS, when you put in a share the chance for good or bad payout is the same every time. Regardless of if the pool is on a long block. Therefore the incentive to mine is always the same. ("I will pay you $0-100 per hour for your work")

With proportional, if the pool is in the middle of a long block then you know in advance you will get lousy pay for your shares. That is when you have no incentive to mine. When you know in advance the pay will be bad. ("I will pay you $1 per hour for your work")

And no, hoppers don't stay for long rounds. Hoppers maximize their profits by not staying for long rounds. The ones who do stay for long rounds are the people giving away their money to hoppers.

If you are a hopper, fine. But please don't spread lies on the forum. Don't believe the FUD, guys, let the proportional payment system die a natural death.

Glad you like it


Reject rates now seem very different from user to user. Currently I have 12 (0.02%) rejects from 36 hours of mining. That's on BTC. On NMC I have 1 reject (0.01%).

High rejects could be not only stales but also invalid shares due to overclocking too high. The BitMinter client will show a count of miscalculated proofs of work (next to the bomb icon), and not send them to the server. I believe DiabloMiner also detects miscalculations. What happens is the CPU double-checking the proofs of work generated by the GPU. Not sure about other miners. Some miners might send them to the server which would result in rejects.

The NMC rejects always or often being higher than BTC rejects might be the miner ignoring long poll notifications because it sees the bitcoin block isn't changing to using a new parent block hash. BitMinter client won't do this, and I believe new versions of cgminer won't do it either. Or do you need to use an option for it to work well with merged mining?

Hmm, can't think of any other reasons for high stales at the moment.