Glad you are getting good performance.

I understand that you are cautious. It's a good thing to be careful about what you download and run off the internet. I hope to become a person that people in the bitcoin community can trust. But I'm sure that will take some time. There's nothing bad in the miner (except probably some bugs). I made it to promote my mining pool. With the 5% promotion I am also giving away a total of 150 bitcoins to promote the mining pool.


You can also run a different miner with my pool. You won't get the extra speed of my miner, but you still get the 5% bonus pay, and very few stales.


That reminds me, I have to implement voluntary donations soon.


At the moment I'm just losing 150 BTC. But I hope in the future people will be willing to set a voluntary donation percentage in their account and donate some coins. The client is part of my strategy to make my mining pool better than the other pools. That way I will hopefully make some bitcoins from my software in the future.


That's how much work the client is holding at the moment. 1 work unit = 1 "getwork" from the server. The client tries to hold a few ready at all times so the GPU can always be kept 100% busy. If there is a network issue, the number will drop to zero after a while, and shortly after the GPU will become idle.


Yeah, a lot of people request additional statistics in the miner. Adding this to the TODO list.


Good idea - added it to my list!

Yes, I will at least add OpenCL mining on CPUs in the near future, which should increase speed by a lot. But I'm not sure if it can compete with the fastest CPU miners available - I haven't tried OpenCL on CPU yet. We'll find out soon.

Also coming soon is faster mining on VLIW5 GPUs, more statistics/information and probably a switch to another payment method. More and more people pool hopping these days, and delayed statistics doesn't prevent it - it only makes it more difficult. Plus, having live or near-live statistics is nice.

D'oh! Accepting underscores in the username was a bad idea when underscore is used as a separator between username and computername. Your workers can't log in now.

PM me what you'd like your username to be and I'll change it.

Are you sending it to the same URL as the regular getwork requests?

Look at the X-Long-Polling header in the responses to your regular getwork requests. They tell you where to send a long polling request, which may be a different URL.

I'm getting 0.048% stale in my own pool with my own miner software. Example: 13 stales and 27046 accepted proofs-of-work.

I couldn't tell you if it's my miner or pool backend. I haven't tried running a different miner for a long time to see if there is a difference.

But I would imagine it depends mostly on the miner software, the pool backend software, and the load on the pool server.

You could try my miner and compare with other miners/pools you tried, see if it helps: http://bitminter.com

Edit: I wrote both the miner and pool backend programs myself - it's not pushpoold like most pools.

I built my own pool backend as well as miner and web application.

Yeah, it would probably have to be with high fees. And to reduce the risk of going bankrupt I'd better wait until the pool is bigger. From what I heard Swepool had to switch from PPS because they were losing too much money. Maybe I should take that off the webpage - but it is something I'll consider a little later.


It's both. I will add more stats as soon as I can implement them. But I think it's best to switch to another payment method before showing how many proofs-of-work have been submitted in the current round. Showing that number would make pool hopping extremely efficient.

Another 50 bitcoins minted - good work, guys!


Cool that you like it I agree with what you're saying, and I do think most people will want transparency.


I will add OpenCL mining on CPU soon. Hopefully that will be quite fast. It will require installing AMD or Intel OpenCL drivers to run though.


Yes, very good explanation - shows why pool hopping will always be a problem with the proportional payout method.


Yes, PPLNS doesn't necessarily pay for all shares submitted while working on a block. To some it would probably seem unfair not to get paid for all their work. If you think about it, it doesn't really matter as long as you mine 24/7. But if you mine a little now and then, PPLNS can become very random for you.

Also, proportional is easy for people to understand, and they can even keep score on their end and verify that the pool server isn't cheating them of shares. This isn't easy if the pool server calculates your payout with some complex formula based off of a large amount of numbers. I liked proportional because it is so transparent. But the problem with pool hoppers seems to be growing in the pools, and I see many pools run other payout methods now. I don't want users who come and go to "cheat" money away from the 24/7 miners in my pool.


It's a pretty new method still, but you can find at least one here in the forum, among the big stickied pools.

There is also a very interesting payout method called shared-maximum-pay-per-share. It seems more fair than PPLNS. But it sounds a little unconfortable to delay payments. And what will potential new users think about a pool that is behind on payments? There is some info on it here: http://eligius.st/wiki/index.php/Shared_Maximum_PPS

I think PPLNS and SMPPS look like the best two. Not sure which one I like better.


There will also be a place to see complete earning history with transactions like in internet banking. The 5% bonus will show up as a separate transaction in your account. That and more is coming soon.

I assume it's a deal breaker because of pool hopping?

I don't have any specific plans, but I have been thinking about the different payout methods. I realize it will be tough to prevent pool hopping with proportional payouts. Delaying stats may work for DeepBit, but it would not work as well for a smaller pool (or stats would have to be delayed much longer).

I think paying for last N minutes is vulnerable to pool hopping too. The more shares were submitted the last N minutes, the less they are worth. And the higher the pool hash rate the better the chance of creating a block. If many shares were submitted and hash rate then dropped: time to pool hop. You don't want to work alone and then give all the money away. If few shares were submitted compared to the current hash rate: time to come back again. Someone else is likely to find a block and you want to get paid.

Maybe "pay per last N shares" is the most fair. If pool hash rate drops there is less chance someone else finds a block that you get paid for. But also you will take over more and more of the N shares at an increased rate, "pushing out" the shares of other users.

Interesting charts on different payout methods: http://eligius.st/~luke-jr/samples/800MH/

I'm open to suggestions.

I think I misunderstood what you meant. What you are talking about will of course be implemented. What I have in mind is that you would click on a block from the block list and come to another page showing how the earnings were split between users. It could show username, number of shares, and BTC paid. Once I get voluntary donations implemented it could show that as well. And also transaction fees and rounding errors. In short, a page to show where every little amount of the bitcoins we earned went.

This may seem like a breach of privacy to some users. But I think it is important for users to be able to see everything that is happening - how else can they trust the pool? What do you think?

Ok, that's a good point. And I think the answer cannot be simply yes or no. If he continued the same work after he should have known it served no purpose, then I think his work was a waste and he should not be paid. If he just arrived back with his results 1 second after the other guy, it would only be fair that he would also be rewarded for his efforts. Perhaps one could have a grace period of a second or two after block change. "You wasted some work, but it's not your fault, so you still get paid."

I don't think this would matter as these stales are the same for everyone and won't affect your share of the payout. But it might have a psychological up-side seeing 0% stales even if it isn't true, and even if you just get the same amount of bitcoins as before.


Right. The cause for some stales may be the miner, and for other stales it's just that it takes time for the mining pool to notify all miners, or that the miner delivers a proof-of-work at the same time it is notified that it is stale.

I think if some users have more stales due to the miner they are using, it doesn't make sense to pay them for those additional stales.

Other than that all users would probably average the same rate of stales over time. In this case it doesn't make a difference whether you get paid for stales or not, you would still get the same share of the 50 BTC. It might have a psychologically positive effect to get paid for stales though?

The other side to it is that the mining pool is competing with other mining pools, so keeping the rate of stales down means a little more money for all users. Consider 50% stales versus 0% stales and a user with 10% of the proofs of work. With 50% stales it takes twice as long between every 50 bitcoins minted by the pool. Assuming all users have 50% stales it won't matter for each individual payout whether users are paid for stales or not. But it does matter whether you get a payout of 5 bitcoins every day versus every two days.

If the pool and/or miners are wasting 50% of the work, then they lose 50% of the potential income.  For 1% waste the loss is 1%. That said, it is impossible to get to 0% stales, because absolute synchronization is impossible in a distributed network. But getting closer to 0% means more money for everyone in the pool.

Well put. If you build a new rig today specifically for mining bitcoins, then that's a gamble on bitcoin's future. Mining and selling the bitcoins immediately would take a long time to pay back the hardware at today's difficulty and bitcoin value. Mining and keeping the bitcoins might be a success though, depending on whether the bitcoin is a success.

I wouldn't advise a friend to build a new mining rig today if they didn't think it was fun and wanted to take a gamble on the bitcoin. But some do think it is fun, even CPU-mining, to be part of a bit of a revolution.

Availability and prices for 5970 not looking that good on ebay, though.

I bought a cheap refurbished 5970 today. Yay!

You could try my pool. It is a smaller pool so you get higher variance, but I'm giving away a 5% bonus on all work done until we have produced 60 blocks. We also have few stales, and a custom miner that is quite fast on 69xx GPUs (but you can use any miner you want). It will take a bit longer between each time you get paid, but you'll make more bitcoins in the end.

Too bad the adapter is expensive, or this could have been a great idea. A cheap laptop with a weak CPU would suffice, and I would think that in general a laptop uses less electricity than a desktop.

If you'd consider mining in my pool (http://bitminter.com), I'd sure appreciate the help getting this new pool going.

I'm paying 5% extra until we have created 60 blocks, so it should be better for you than solo mining.

It's a bit of a chicken-and-egg problem starting a new pool. Everyone wants to mine in the big pools, so how do you become big? But to get things started I'm giving out 150 bitcoins in the form of a 5% bonus on all work done up to block 60.

Next two things coming are pool rate display and miner optimized for radeon 4000+5000 series.

Anyway, if any of you guys modify a 6950 I'd be interested in hearing how it goes. There's probably a chance to render the card useless, so I wouldn't advise anyone to do it, but it does sound interesting.

This is exactly right. Stales equal wasted work. Stales are proofs-of-work in the way that you prove that you were working. But were you working on something useful? No.

Pools are not paying you to burn GPU cycles. They are paying you to work towards finding those magic bits that can create a new block. Working on stale data will not create a new block.

This is why I worked hard to reduce stales in my pool backend and miner. In my current session I have right now 19848 accepted proofs-of-work and only 14 stales. Reducing the stales has real value. It has basically the same result as making a miner faster.

Consider an analogy: You have one employee in an office working, and another reading the newspaper. Both are doing something, but only one is doing something useful. Which is more fair for the company to do? Pay them the same, or pay only for useful work? If the company has 50 bitcoins to pay out as salaries, should both employees get 25 BTC each?

If you pay for stale proofs-of-work then everyone else will be paying for the useless work from that guy who's running an old miner without long polling support.

Yes, some 6950s in the hardware comparison chart are delivering some really high numbers. That's because they are hacked to "become" 6970s. This may be possible on your card as well. You can read more about it here: http://www.techpowerup.com/articles/overclocking/159

I think in some cases the locked shaders may not be functional, and unlocking them can give you a GPU that doesn't work right. I've never tried this though, so I don't really know what I'm talking about. Just if you decide to try it, make sure you read the "what if something goes wrong" section.

Anyway, I'd be interested in hearing if you get any higher performance with my miner. It's optimized for 6900 GPUs. It's at http://bitminter.com if you want to try it.

Yeah, the CPU-mining code is really bad still. It hasn't been a priority, but I will implement OpenCL mining on CPU (with Intel or AMD drivers) soon.

If that's not fast enough, I'll do by-hand optimized assembly language with SSE instructions. An assembly language solution will probably be far down on the priority list though, as it will be a lot of work for probably little gain. I would need to make shared libraries for Windows, Linux and Mac, and invoke those from the Java Virtual Machine.

The miner seems to do better than the other miners on Radeon 69xx (VLIW-4 architecture), and GeForces.

I still need to optimize for VLIW-5 (Radeon 4000 and 5000 series and part of 6000-series).

Today I was able to find a refurbished Radeon 5970 at a decent price. I'll have it tomorrow and start working on speedups for the VLIW-5 cards. By the way, I thought 5970s were supposed to be impossible to get? Lucky find, I guess...