And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale. So if i understand correctly, slow miners will be subsidised from money of honest GPU users ? Just asking. Your question also imply's that the CPU miner's are using a higher askrate, which at the time of writing this the CPU miner's appear to be using a askrate of 10 or less, so no. But, if they were to use a higher askrate (say 600 seconds), then yes, their profits would be subsidised from the GPUs. We've done this to accommodate them while we work on the CPU pool. We're hoping to have it up and going in the next few weeks. When we launch that pool, we'll be back down to CurrentBlock submissions only. |
|
|
|
(I simply cannot stay outside)
Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.
< sarcasm > Well well....look who showed up. Guess what we did....WE STARTED OUR OWN POOL!! I know what a concept, right?! < / sarcasm > First off, I think you should apologize to Geebus and I for calling us trolls a few weeks back. That would be the polite thing to do here. Trolls don't release their own pool AND miner, they just talk shit. We talked about this with you, and wanted to help your pool become more efficient, but we also had problems with the way your pool was being run, and as a result of that you called us Trolls and then ignored us. Apologize to us first ON YOUR THREAD, which would be the proper thing to do, then we'll address you on ours and we can continue this conversation civilly ... if that's what you want. Or we can treat you the way you treat us. It's up to you. |
|
|
|
And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale. That is not what is stated in the OP. - Anti-fraud protection. We only accept shares from the current block, in the current round. This pool is in beta, and many things have changed since the original post. This was one of the changes.
Edit: Even today, FairUser stated that the pool only accepts work from the current block. [...] they risk working too long on a getwork and the network's block count increases by one making their work stale. [...]
And that original post is now updated. Geez, we've been live less than 48 hours and we're still in beta....chill out. It's very obvious that you're not a fan of our pool, but seem to love slush's pool, and have come here to stir up trouble by bringing up CPU users time and time again. If you don't like our pool, and you're stuck with only your CPU, then I'll feel sorry for you. But I could be wrong...so what is it your using, a CPU or GPU? |
|
|
|
So you admit that your pool too favors faster miners when you specifically (incorrectly in every way except your one shortsighted emotions over statistics way) chided Slush's pool for doing so in your OP.
"Testing with" and "favoring" are two different things. We pay CPUs and GPUs the same amount for each share. We don't "favor" either one over the other. Your pool asks the miners to keep a high Share/GetWork ratio. In order to accomplish this, your pool requests that miners process the entire solution space of every single GetWork before requesting another GetWork. This means that the slower a miner, the more likely that that miner's solutions will be Stale. True. So if the CPU user's can't handle that, then it's time for them to upgrade to a $89 video card and get with the times. Simple as that. |
|
|
|
-a 5 -t 8 -o host@host.com:#### -u XXXXXXXX -p XXXXXXXXX is how you are supposed to set it up
I'm using it with deepbit's pool (deepbit.net) it also works with btcmine.com's miner
Here's what I'm trying: C:\Users\User>C:\Users\User\Downloads\bitcoin-miner.exe -a 60 -t 4 -o http://bitcoinpool.com:8334/ -u MYusername -p MYpassword bitcoin-miner 0.3.2 Copyright (c) 2011 Ufasoft http://ufasoft.com/open/bitcoin4 threads Using SSE2 0 MHash/s It just sits their @ 0 MHash/s. I also looked under wireshark, and it's still not passing the "Authorization" header. I don't see how a pool could track this miner's answer without using the Authorization header to know which worker is who's.... <very confused>  Please correct me if I'm running the command incorrectly. I don't see much documentation on it. |
|
|
|
I just tested ufasoft's CPU miner. I was unable to connect to our pool. I used wireshark to take a closer look at what is going on. Here is what I found: POST / HTTP/1.1
Content-Length: 43
Host: bitcoinpool.com:8334
Cache-Control: no-cache
{"method": "getwork", "params": [], "id":0}HTTP/1.0 401 not authorized
The red text is the response from our server. The blue test is the request to our server. It appears that this CPU miner is somehow missing the "Authorization" in the HTTP headers when making the request. I haven't used this client before, so I attempted to use it on slush's pool too. It didn't work their either. So how many people have gotten this miner to work?? I would also be curious to know how you got it working...because I can't see how it's Authenticating to the pool servers. I did enter my login and password on the command line, but it doesn't look like it's sending that information to the server in anyway....which would be the a very good reason why it is not working for some of you!  Hopefully ufasoft will fix this issue soon. (This was tested on a Win7 x64 w/ Intel I7 quad core.) |
|
|
|
Think of it as printing lottery tickets instead of money, you printing outthe chance for a chacne at some real money, and if someone can go through the paces for gpu mining for throttable minimg for me and can perhaps help me set it up I would arrange payment in a say, tv card for the US, I have a couple AVERMEDIA ATSC cards around and I'll mail you one in payment if you can help me get setup mining wiht my cpu and dual gpu on a single card. Please. email kc0edo@yahoo.com or @tinkerToyTech on the twitter and that facebook thing I'll be happy to help you out, no payment is necessary. Maybe a donation once we get you up and you've been able to mine for awhile. PM me the following information: - What type of video card do you currently have - What the driver version is for your video card |
|
|
|
By asking a CPU Miner (or any miner that isn't at least some X% of the network's total power) to process the entire getwork solution space before performing another GetWork, you are dooming that Miner to a very significant percentage of Stale shares.
Yup, you're right. CPU miners are doomed either way. Either they ask for new work so fast that they don't even have a chance at getting through 1% of a single getwork request, or they risk working too long on a getwork and the network's block count increases by one making their work stale. CPU miner's are simply too slow to be able to run at a high efficiency against any pool, or even the bitcoin network at this point. Because the average block is solved in less time than it takes on a average CPU to process even 1 getwork all the way through, it's really not worth using a CPU to mine for bitcoins at this point. When taking GPU's vs CPU's, it's truly a night and day difference. You could take the most powerful DUAL CPU/QUAD CORE Intel server (~12,700 khash/s) and run it against a ATI 5750 card (~150,000 khash/s) and the ATI card will smoke that server hands down...we've tried. We built and tested this the Pool with GPU's. Could you imagine us trying to build and test a pool with CPU's?! ROFL  |
|
|
|
Well, it is worth what it is worth. I'm now using your miner exclusively, so there you go  Don't let my word be taken the wrong way, you've done an amazing work. Not only did you get the miner to search the full key space, which is the way I like it, you also give out very helpful information while mining, something that was really lacking. Kudos to you, and btc's too once this miner renders me some Thank you very much! |
|
|
|
There is no guarantee that a solution exists in a 'getwork' data unit.
True. Then again, some getwork will have 2, 3, 4, 5, 6, or more answers. The most I've seen is 7 answers being found in 1 getwork request. The more time you give to a sample period, the closer you get to a 1:1 ratio of [shares submitted]:[getwork request]. Better to rename "efficiency" as "luck." It is more clear.
No, cause the whole process of mining is based around "luck". When we talk about "efficiency", we're talking about how much bandwidth and resources the miner is causing the server to use. Our goal was to reduce the amount of used resources to a minimum while making sure the client isn't negatively impacted. Sorry for the misunderstanding or if we were not clear enough. |
|
|
|
10 Getworks, 9 Answers = 90% Efficiency.
For a good basis of comparison, the original poclbm sits at around 17% efficiency on my cards, with a 10s askrate.
While I've always felt more comfortable with iterating the full getwork, to the point of having done my own opencl miner integrated on bitcoind just for that, the mathematics you are describing are really a flawed kind of statistical proof. Yes, you do get a much better coverage of the getwork (which is what you call efficiency) and the original miner just throws away the rest of the work once a solution is found, so it is never as "efficient". But that doesn't mean it is slower or worst, as we are basically trying to find a solution on a random pool of numbers. You are correct, it is not slower or faster in finding shares. Our focus was simply to reduce the amount of resources (bandwidth and CPU time) on the server. That's what we're focused on; reducing the amount of bandwidth and resources used by and for the server. So you count the number of solutions vs the number of value pools, whereas the original miner counts the number of value pools with at least one solution.
In the end I would argue the success rate will be larger for your miner because the network lag is smaller, as the miner doesn't request a new work set for each solution found, but that's about it.
I don't think that our modified miner finds more shares or blocks. All the tests I've done show about the same number of shares. We're hoping that by having more miner's that can get the same number of shares in a given time and reduces the load on the server, we'll be able to support more users. We're also hoping that more users means more blocks solved. The 17% vs 90% description is really misleading!
I don't believe so. Perhaps our description of what we mean by "efficiency" was a bit misunderstood or lacked a sufficient explanation. Sorry for the misunderstanding. |
|
|
|
oh I use -v -w 128 -f 0 or -f 10 for my GPU...
And I do not think ufasoft's miner works, at least not for me... what SSE2 miners work?
Honestly I'm not sure. After spending $45 on 64 CPU's from Amazon's EC2 cloud for only 24 hours, and getting almost nothing in return, I abandoned all the CPU's miner....personally speaking. I spent the money, got a couple GPU's, and the entire time I was testing the pool I used GPU's. Geebus may have tested some CPUs. So any and all feedback from the CPU's miners out there is a BIG help for us. Thank you in advance. |
|
|
|
Current Round Stats are back up on the index page. We had to resolve an issue with slow response and timeouts on the database queries. All is well now.
For now I have the highest efficiency and I'm 3rd in shares if we don't count the geebuses and the goldys else I'm 6th all that with a non-constant 270Mh/s Also, can this be run with ufasoft's miner? I didn't get it to work. and the poclbm gets me only 3Mh/s (vs 20) AND lowers my GPU mining by 25Mh/s I honestly haven't tried ufasoft's miner, so I'm not qualified to answer that question. Also, you might want to have the "-v" flag added to the poclbm-mod.exe so it will attempt to use vectors. I noticed a speed improvement on all three of my boxes when I used vectors. If you figure out what's going on, please post back here. I'm @ work right now and can't really test anything at the moment. |
|
|
|
If people with CPU miners are unsure if they should join this pool — i.e., if they can live up to 1% efficiency — here are some numbers from the fastest of my CPU miners (and you will see it's pretty slow):
I'm running jgarzik's cpuminer single-threaded with the sse2_64 algorithm on a Core2Duo E6550 @ 2.33 GHz and a scantime of 7 seconds, which gives it a speed of 2,452 ± 272 khash/s (p=.95, based on 56,533 getworks).
Now, out of those 56,533 getworks the miner has delivered 224 POWs. Ladies and gentlemen, that's a whopping efficiency of 0.396% (and so this miner doesn't qualify)!
That said, I do like the share-based payout system…
Cheers,
OK, we made a change. Auto-banning is turned off for now. CPU miners are safe. We will no longer look at the 1% Efficiency as a means of banning people. Instead, if you miner make more than 30 getwork request AND has not submitted a share in 60 seconds, you'll be temporarily banned for 5 minutes. If your miner is getting a new getwork every 5 to 10 seconds AND has not submitted a share in 60 seconds, you'll be OK. We are trying to prevent getwork flooding or as some have called it the "fire hose" method for trying to find shares, because it's horribly inefficient and ultimately cuts the CPU miners short. Working on your getwork for more than 5 or 10 seconds is preferred, but you probably don't want to work on the same getwork for more than the current average time it take to find a block (based on a average of the last 100 or 1000 blocks). Ahh, gotta love the CPU's too... |
|
|
|
I think I got banned from bitcoinpool.com (and the miner does work either) because I refreshed the page too many times Could you unban me please  PM me your account name on the pool. Wait, I see a "nster" account and it does not have the banned flag set. You should be able to mine with no problems. Please keep in mind we are working on the site during this time too. So if a page says it has an error or something, that'll be temporary and you should try to refresh in a couple of minutes. |
|
|
|
everytime I refresh to see how many BTC I should have, it lowers, why is that? Holy f%^#% I just made myself lose like 0.01 BTC...  That is happening because other people in that time between refreshes have submitted their shares...which increases their earnings and subsequently decreases your by a small amount. Likewise, you will notice that right after you submit a share, your earnings will have increased by a little bit. |
|
|
|
I hope there are no nasty surprises in your closed source code The poclbm-mod.zip for the Miner includes the source code for it. You might want to download it and see for yourself. We based the server on the open source poold from Jeff Garzik, with some heavy modifications though. http://yyz.us/bitcoin/poold.py |
|
|
|
Our pool pays miners equally for each share they submit to the server. Our pool does proportional payments based on the number of shares your miner has contributed to the current round. This pool does not support the “pay-per-share” method seen by some other mining pools, or stupid “weight based” shares which favor faster cards and punishes the fair and hard working miners who have limited resources. Just so that i understand, you meant you don't like the option of either having Proportional or Pay-per-Share? Because if PPS is unfair, the user can simply choose Proportional. Other than that, how is your system not weight-based? I kept reading that sentence more than once trying to understand it; the whole quote above actually. Can you please elaborate? Thank you. Sorry about that, it's 5 AM and I'm tired. The "pay-per-share" pools pays you a fixed amount (in bitpenny's case it's 0.000809494650699530728099606591 BTC) for each share you submit. We pay out the based on the percentage of work you've done: (Number of shares you submitted) / (Total number of shares in round) * 50. That will tell you how many of the 50 bitcoins that you get paid. Thanks for pointing that out. Just updated first post to better explain that. |
|
|
|
We are proud to announce a new bitcoin mining pool has opened: http://bitcoinpool.comPlease feel FREE to join the pool. http://bitcoinpool.com/newuser.phpOur official forums where questions can be asked is at: http://www.bitcoinpool.com/forum/Our pool pays miner for the percentage of work done based on; (the number of shares your miner has contributed) divided by (total number of shares in the round) times 50. Our server is now in Beta, payout functionality has been fully tested and debugged these last two weeks. Additional features will be appearing in the next few weeks as the pool grows in popularity. This pool does not support the “pay-per-share” method (bitpenny's pool) or “weight based shares" (slush's pool) which favors faster cards and devalue's shares over time after they've been solved. Now let's cover some of the finer points of the bitcoin pool. - WE DO NOT FORCE DONATIONS OR TAKE A PERCENTAGE OF THE PAYOUTS. WE DO NOT REQUIRED ANY SIGNUP FEES OR ANY OTHER FORMS OF FORCED PAYMENTS. We do encourage and are thankful for any donations we receive. Our donation address is: 1AMnDUgnZTZJUcSR5Eevt6PnxWLmdq75Zn- We have set a maximum number of users to 2000. We will be able to increase this number if a majority of the miners on our server are mining with our efficient bitcoin miner. - The solved block is equally paid out to all those who contributed in the round. - Anti-fraud protection. We only accept shares from the current block, in the current round. - Anti-flood protection. Our server ensures that user's are not making an excessive number of useless requests to our server, and bans them by account and IP address in the event abuse is detected. - We show the stats of all users in the pool because we believe in being transparent. By showing all the stats of each users, everyone can determine for themselves if something is not right (like the server operator taking bitcoin's off the top). - We are the only bitcoin pool that shows the efficiency of the bitcoin miners. This is VERY important because we can now see which miner's are causing an excessive load on the server. If this is a problem for you, please update your miner to our modified version of m0mchill's miner that is MUCH more efficient. - We are the only bitcoin pool that has released a modified version of a bitcoin miner (m0mchill's) that can achieve 100% efficiency. The more efficient each user is, the more users we can support on the server, and that means we will find more blocks at a faster rate for the pool. - The listed shares and efficiency of each user is reset at the beginning of the next round. - You can use multiple miner's on a single account, however you will not be able to see the individual stats of each miner if you choose to do so. MINING EFFICIENTLYFor the sake of understanding what we mean by “Efficiency”, let us define it for you. EFFiciency = (The number of submitted shares) / (The number of requested getworks) * 100. Geebus and I raised a very important question in m0mchill's thread, and that question was “why doesn't the miner work through all (2^32 or) 4,294,967,296 hashes?” The answer we got was not a satisfactory or a legitimate response to the original question, and we objected with real stats showing that decreasing your askrate for getwork request does NOT increase the probability that you will find a share or answer quicker. In fact, you can find more than 1 answer/share per getwork, and that simply requesting a new getwork every 10 or 20 seconds is not the best route to finding shares. The bottom line from our research was this: - The same number of shares can be found in a 10 hour period using a askrate of 10 seconds OR our more efficient miner. You will get about the same number of shares either way. - Because the same number of shares are found in a given period, there is no reason why people should be using a decreased askrate. The goal is to look for bitcoin's more efficiently, and when the miner's efficiency is closer to 100%, the amount of resources and bandwidth on the server is DRAMATICALLY reduced, and that means we can support MORE USERS. - More user's means we as a pool can find blocks faster! In order to make this happen, we had to make some changes to m0mchill's miner. We now use what is referred to as a “variable askrate”, which means that the miner looks at the average speed of your card as it processed the previous getwork, and adjusts the askrate so your card will search the entire getwork for any possible answers. In addition to being more efficient, we also show the current getwork you're working on, how much of that getwork has been processed, your efficiency, the percentage of invalid/stale shares, and the percentage of empty getworks. Here's a screen shot of our miner, and as you can see it's a bit different than m0mchill's original miner.  If you would like to see the efficiency of your existing miner, then join our pool and run your miner for a couple of hours to see how efficient it really is. When you're ready to get a more efficient miner, you can download our miner and watch your efficiency rise dramatically. For all those who said we didn't know what we were talking about, you would be well advised to try this miner before making anymore comments. We spent months working on the code of m0mchill's miner, countless hours of testing and statistical analysis, and it is by far the most efficient miner out right now. But why should you believe us, just because we said so? No, you should try it yourself and compare it to your existing miner, then make up your own mind about whether or not this is a more efficient miner. You can download our modified miner from: http://bitcoinpool.comYou can sign up for a new account at: http://bitcoinpool.com/newuser.phpAdditional Frequently Asked Questions can be found at: http://bitcoinpool.com/faq.php Please feel free to ask any questions you may have. We will do our best to answer your questions. We are excited to launch this new pool and invite everyone to come jump in with us. We look forward to seeing you all in the pool, Fairuser & Geebus |
|
|
|
 This is based on real data from the rounds for prev difficulty (36k). As you can see, it turns out if you would be only joining about 2250 seconds after round start, then while mining with pool, you would be earning 3.5% more than those mining all the time. And since this plot is based on actual distribution of time to find blocks, it may vary in future, and it's hard to know ahead of time what moment is perfect. Thank you for this great graph. It helps prove that this type of "weighted" system is completely unnecessary and flawed. Not accepting any block older than _currentBlock_ was more than sufficient to stop cheaters, and slush knows that. This new "weighed" system seems to screw those who worker longer and harder for the pool, which in itself is incentive for long term miner's to find a new place to mine. And if those of you who were under the believe that this "weighted share" system was going to stop those "cheaters" from "pool jumping", I guess you get to think again. If anything, this graphs shows that the weighted share system helps those who jump in and out of different pools while punishing those who continuously stay in slush's pool. Don't worry folks, a new pool is just around the corner, and every share will be treated fairly and equally. Testing is underway as we speak.... |
|
|
|
|
Show Posts
