Bitcoin Forum

Here's an unlocked thread, for discussion of BitcoinPool.com (http://www.bitcoinpool.com/).

I believe in free and open discussion.  This thread will not be locked.

Has anyone that's been at bitcoin pool for a while seen a better than average return vs a PPS pool?

I just built a mining box this past week that gets ~600Mh/s and want to know which place would give a better return.

It looks like I get about 0.32 BTC/hr at deepbit doing PPS, or roughly 230/mo. I like the steady payout even if it's 10% fee.

Of course I like the idea of no fees at bitcoinpool but my efficiency seems to vary a bit (80'ish-110) when leaving the client on 24/7 and 600Mh/s and is a small part of the growing total hash speed.

I would recommend avoiding bitcoinpool.com

Actually, that's pretty much all you do (http://bitcointalk.org/index.php?action=profile;u=5937;sa=showPosts). No explanation why, just a quick attack and sidle off. Care to change that, and provide some more detail this time? Otherwise it's difficult to escape the view that you're just trolling.

It is my opinion based on experience, not an attack.  I am sorry if you share a different opinion.  That is why we have freedom of speech.

I have very little opinion on this pool, as I don't use it. I'm just curious as to why you have this opinion, and seem so keen to share it multiple times. I'd like you to elaborate. Rather than just saying "don't use this pool" I'd like you to say "don't use this pool because ..."

Don't feed Troll's

Yes you are entitled to YOUR opinion
STOP shouting fire with out any reason WHY

Typical troll --- especially in a new thread

We know Your opinion ... Who Cares

I do not believe I was shouting.  Sorry if my opinion offended you.

Anything beyond opinion, pilgrim? Hell, for all we know you may have a well thought-out and rational reason, one we could all get on board with. Let's have it!

Your still not giving any reason why, thats what he was "offended" about in the first place, you should know that. You don't "have" to explain, but just know it's not your opinion that he is bothered by.

Recommendation ignored due to lack of reason, failure to address original question, and troll meter pegging loudly.

Anyone else?

Ok, so I have partially read through the locked thread and I think I have a partial idea of what the deal is, but does someone care to sum up exactly what the beef/problem/drawback of Bitcoin Pool is?  Why is there a debate or a problem to begin with?

I've been contributing to it for a few days now and haven't seen a problem, but I haven't really examined it in detail, which is why I ended up in the locked thread and now here.  So a summary explanation of what's going on would be great.

I haven't seen and credible reasons to avoid them either.

I'm chalking it up to general devolution of the thread due to trolling, ignorance, arrogance, and ego. Par for the course of web boards all over the internet.

I'll see what happens over nite
for now since the eff rate went into effect
I'm getting more return with slush and his crapshoot for my cpu's
than here with my gpu

There have been multiple issues over time, but many had been identified and resolved due to the discussions in the original thread. Technical discussions that the owners of the pool were not happy to have even though solving the issues only made their pool stronger and better for all of its users. I personally think that the main reason that the thread appears so hostile is because the owners were taking every single technical statement personally and lashed out with hatred and obscenities.

----------------------------------------------------------------------------------------------

Here is a quick rundown of the history of the technical issues attempting to leave out the emotions and misunderstandings:

- The first big issue was over FairUser and Geebus' definition of efficiency which was different from what the rest of the community understood.

- Once the difference in definition was understood, it led to the realization that the initial implementation of their pool and custom miner would cause a significant increase in stale shares for their users. FairUser and Geebus resolved this by giving users credit for stale shares even though they were stale.

- Crediting stale shares caused the pool to favor miners that have a high percentage of stale shares. Paying such miners for stale shares requires that they be subsidized by the stronger miners. FU and G decided that this measure would be temporary until they could fix the root cause of the stales.

- FU and G fixed the root cause of the increased number of stale shares with a new version of their poclbm-mod GPU miner which polls a local bitcoind process looking to see whether or not the block has changed. This wasn't the best way to solve the problem, but was mostly effective.

- The rest of the community was already working on a different way to solve server efficiency and stale shares by using Long Polling. Long Polling was released just a few days later and was found to be more effective, so FU and G added Long Polling support to their pool.

- Purely a statistical bug, but it caused some significant discussion; The stats webpage was pointing to the wrong block in Block Explorer, causing confusion for people trying to track down payments statistics.

- At this point, everything was pretty much stable and most of the concerning technical issues that negatively set them apart from other pools had been worked out.

- Then, one of the pool's users posted with concern about the fact that they were seeing severe (upwards of 40%!) fluctuations in the pool's hashing rate. And that the fluctuations seemed to correlate to miners "jumping ship" during long rounds. This is exactly the indicator that one would expect to see (though not proof) if the pool was being attacked by miners using Raulo's Pool Hopping exploit. This issue has not been resolved at this time.

----------------------------------------------------------------------------------------------


Technical issues are a fact of life and every single pool has had them and will continue to have them in the future. I do not begrudge any pool or pool operator for their technical issues and, in fact, I highly applaud pool operators for taking the work upon themselves and creating competition in the market!

I also do not begrudge a pool operator when he is unaware of or ignorant to technical issues and/or doesn't initially understand the reasoning behind them. None of us are perfect, and this is an extremely technical community that requires a lot of explanation.

I do, however, have major concerns whenever a pool operator is constantly attacking and hateful toward anyone that dares say anything at all except for thanks. Users that attempted to contribute their mining power to the pool but had small (sometimes ignorant) questions were often met with scorn and bile as if the operators despised everything about them. And every technical statement/question was met with skepticism, denial, obscenities, and hatred; as if the operators were lionesses trying to protect their cubs.

No matter what the technical or financial merits may be, these are not the kinds of people with which I trust to do business.



Edit: Added mention of the statistics error pointing to the wrong block.

I fully agree with your post.  Very well written.  I agree with you that one of the reasons for all of the hostility is because the pool owners quite often lash out with harsh language and obscenities.  They are also very quick to threaten expulsion from their pool for anyone who disagrees with them or dares post a negative opinion on the forums.  They also follow through on these threats, as I am aware of several users who have been banned from their pool for speaking up.  I also fully concur with your conclusion that these are not the type of individuals that I would trust or do business with either.

The main source of drama and the primary draw back on BitcoinPool.com is around miners hopping out of the long blocks. FairUser and Geebus presented their pool as superior in 4 aspects:

1) Their miner, a modified version of poclbm, which main change is an askrate defined by your hash/s as opposed to the 1-10sec offered by the original poclbm. Their argument is that giving enough time to the miners (based on their respective hash rate) to complete the hashes they request will increase the efficiency of the pool and eventually decrease the blocks completion time at equivalent speed when compared to the other pools. The concept is certainly interesting, and the operators invited miners to come and compare their speed with stock poclbm vs the moded miner on their pool. This invitation is at the origin of MOST of the hoping on that pool imo.

2) They distributes rewards through a share based system. They point that alternative as the fairest way to pay out their miners. This was a direct criticism of slush's pool.

3) They display full stats, live, for everyone to see, as a proof of "fairness". This time they're going after Tycho's delayed stat.

4) They don't charge any fee, that they label as "forced donations".

Putting aside the fee issue, that I consider is a fair reward for the job done by the operators, the community confronted FairUser and Geebus with their declarations: As xenon481 said, the longer askrate implies more stale shares; on the long term score based systems payed the same reward per shares contributed as a shared based system; score system and stats delaying were counter measures against pool hoppers. Even though FairUser and Geebus' idea regarding askrate had its merits, exposing its weakness resulted in much drama.

Eventually the issue focused on BitcoinPool's vulnerability to Raulo's attack. FU and G indeed made a point of accusing slush of being dishonest and exploiting his pool and disadvantaging the slower miners with his score based system. Slush confronted them, explaining that the score base system was to protect against pool hopping. FU and G refused to aknowledge the validity of such attack, so slush offered to perform the attack (under his credentials) with his 3GH/s on BitcoinPool's 10~15 GH/s. FU and G turned down the offer, now accusing slush to try to attack their pool (implicitely admitting the attack is now possible and very real).

Geebus eventually admitted to personally despise slush, Tycho and slush were then accused of trolling BitcoinPool's thread and pool, and FairUser locked the thread after posting an already defeated argument as of why he'll stick to share based rewarding while exposing full live stats at the same time.

Ill weigh in here. Most of the above is true however towards the end they did actually accept slush's challenge right before it was locked out. Also much of the confusion in the thread came from members AND non-members adding nothing constructive to the conversation mostly complaining about long rounds even though the pool was doing fine for its hash rate. There was an awful lot of critisim going on, much more than any other pool and im sure that was frustrating for two pool operators who weren't making a mint off running it like Slush( No disrespect intended. When people even mention Bitcoinpool u imediately get people bashing without giving any good reason other than they dont like their attitude. But the best thing about the pool is its basically like setting up your own private pool and linking it with other people. if ur system crashes or u turn it off for the night u still get what u worked towards for that round and its really simple rules. Im sure i could go to slush or tychos pool and make the exact same but things would be slightly more complicated and i cant look at my stats page and say crap one of my units is down jus by getting on the net. You guys should still try the pool before bashing it despite what you think of Geebus & Fairuser

Mathematical proof is not real world proof, it is numbers making sense. I'm sure we would all like to see real world proof of this. The thread devolved into fights over simple definitions, terminology and hardheadedness between the math theory claiming the research to be irrefutable vs an actual test.



If I was a pool operator and another operator came into my thread and offered this up I would see it as hostile and be apprehensive also. He has his own pool. Even if is stats aren't constantly updated, anyone can calculate the sweet spot with some accuracy and try it out. There is no reason to repeatedly challenge another operator to exploiting their pool at the detriment of their users either way. That was adding fuel to the fire at a time when the whole conversation was going downhill.

Thank you for your support FRanz33.  I locked the thread because of the trolling and flaming, and I think I made that clear once before.  A new forum on our site will be active in the next week. We feel this is necessary to help keep focus on our pool, efficiency, and how it affects mining.

Geebus did tell slush to go ahead and try it if he wanted, but we had a few conditions we would like met.

1) Tell everyone your handle. I'll even reserve "slush" just for him.
2) Tell everyone how long he plans on trying this.
3) Use our miner, poclbm-mod.  I don't want any more inefficient miners on the pool than necessary.
4) Report your stats somewhere on the forums every 24 hours so everyone can follow along.
5) Establish your baseline or average daily earnings using gribble, before, during, and after the test.

I think this is a perfectly fair and open challenge so long as he doesn't try and hide it from everyone. 

We are still waiting to hear his response...

I guess I'll put in my 2 cents.  In my opinion this pool has the greatest potential I mean you can't argue with no fees.  The main reason I haven't switched all my miners to here is I had one of mine on there for a couple days which there was a combined 2ish hours downtime in those couple days.  So that cut about 5% out right there, also I was watching my miner and it was acting weird once for a couple minutes it was switching between mining and then stating unable to connect.  It very well might have been that it was an unlucky period and the downtime isn't normal but I wasn't sure how much it showed the intermittent unable to connect errors either as I don't just sit and watch it mine all the time.  In conclusion I hope/think it's was/is just going through some growth pains and I'll keep an eye on it and probably bounce back in later.

Edit: looks like my grammar wasn't exactly spot on here sorry.

the downtime was only a recent problem. TBH,IMO, they have the right to be a bit on the aggressive side, they spent countless hours on the pool with no income (ie: fees)

slush didn't just walk in there saying "hey ima assault your pool". He defended his score system, that FairUser and Geebus presented as unfair. He exposed how it was mathematically yielding the same result as a share based pool, and how it protected against Raulo's attack. Now you don't see slush saying how he'll attack Tycho's pool to prove share based distribution vulnerable, simply because you don't see Tycho pretending score based systems are unfair.

Now, it is up to one's opinion to disregard mathematical evidence. If you manage to build a successful pool while remaining exposed to an exploit, the more power to you. It is a different matter if such opinion is the basis of one's criticism of the mathematical evidence. In a public discussion, your opinion doesn't weight the same as a mathematical theory.


For information I tried the pool with the moded miner. I related that part of the discussion because it led to the locking of the thread. To the question "what are the downsides of BitcoinPool.com", i answered "the pool hopping", which is also relevant to the discussion prior to the lock down. And however frustrating it might have been FU and G, you might consider the fact that they're the ones who accused slush of cheating his pool. You should be prepared for a flame war when you go around flaming others. I mean, this is the internet.


Maybe yes, maybe no. I don't speak for slush but i can come up with a few arguments as to why he has little interest in performing that test under all these conditions. I'll elaborate if you so desire. Note also that slush offered to perform the attack under his name before Geebus gave in.

Yeah like I said I was unsure if it was normal but it was just too much downtime for me.  I am glad they seem to be sticking to it and improving it.

Any and all downtime we've had that was not directly posted about in the thread was due to aggressive DDoS and SYN flood attacks against our pool. Someone, or some group specifically targeting us with malicious intent. We've also had attempts made to hack our personal email accounts and personal computers. All of this while being directly and openly trolled by non-members of our pool in the thread about our pool.

All of those things happen to all of the other pools too.

BitPenny even had to completely shut down due to malicious attacks.

I'm having a hard time with the poclbm-mod.zip.  I'm on a Linux box (Ubuntu). 

Diablo and poclbm work great, but poclbm-mod.py does not work.


Anyone know why?  From what I read on line there is a mix up with the windows endings and the *nix endings, but I thought this file was suppose to work with Linux.  As I said, poclbm.py works fine.  I'm running it right now. 

Try "python poclbm-mod.py ..." or if that doesn't work, install dos2unix and run it over poclbm-mod.py.

Freak'n amazing.  python poclbm-mod.py ... works!  I knew it had to be something simple. I'm only on a 4830 so it might take a day or two before I see any real payout :)

I got the same error message and just went with python poclbm-mod.py also. I forgot about the possibility of it being a system format issue.

dos2unix worked for me, but I had to install it.

sudo apt-get install dos2unix
dos2unix poclbm-mod.py

If you're on bitcoinpool it only takes as long to get paid as it takes for the pool to solve a block (which seems to be running long this round). How much is a different question.   ;D

Per the BitcoinPool website: (emphasis added by me)


I highly agree with the site owners that anybody that has an account there should review their security immediately.

Ive been monitoring poclbm-mod since the drive to remove those with low efficiency

what i'm seeing is that it continues hashing the current getwork after it finds an invalid/stale share
should it not get a fresh getwork after finding bad results ???

I also tried using poclbm-mod for cpu
First off my hash rate on the cpu was 20% of what pudinpop's rpc miner were
my results also showed that after the first longpole block change  most block changes were missed
resulting in mostly invalid/stale shares being found

This is NOT a bitch or complaint against the pool or the operators
Just my findings - Yours results may differ

This is a complaint, and a legitimate one as it is backed by your findings.  ::)

Yep, and this is a very good reason why you should use different passwords on each site.  I personally use different randomly-generated passwords for each site, account, worker account, etc.  Be smart and limit the damage someone can do by compromising a pool's data.

another thing I'm noticing
I've only got shares on 4 of 7 blocks
but have a 0 for emp (blocks with out share)

ok its becoming apparent

8 of 18 blocks yield results
9   results below 50%
2   results above 50%
1   results above 75%
yield after 50% hash of a get work    not much

efficiency went from 200%  down to 60%

How can you possibly rate the efficiency of luck ???
It's lucky when you find a share... it's lucky if that or any share finds the block
My luck has no bearing on what happens in the future
My past luck has nothing to do with now

If you use my cpuminer or ufasoft's CPU miner, you will get far more performance on CPU.

poclbm and puddinpop were not built for CPU mining.  That is largely an afterthought, and it shows with lower performance.

Any one notice
no payout since the last totally 120 confirms

22 getshares crunched now 
of 25 shares returned
4 over 50%
2 over 75%

You get the picture ..
16% in the last 50% of the getwork
8% in the last 25% of the getwork

MY point is Yes there are shares to be had in mining the whole getwork
but most are before 50% and certainly before the last 25% of the getwork
mining every possibility in every getwork doesn't seem to give the most

22 is not a statistically significant sample size in this context.  Observing my miner for about a week, the valid shares found in each getwork seem pretty uniformly distributed through the nonce-space to me.

That's not so say I haven't had a bad day or two where I run getworks that mostly turn up nothing at all.  The way the numbers work, you should average almost exactly one share per getwork that is completely searched.  In other words, your efficiency should be close to 100% on average.  I have some days where I'm consistently around 60% and others I'll be at 150%.

And discounting a small sample
makes it invalid ???
it shows that mining every last part of every get work is useless
if you have a fast cruncher you never see the fallout ... wasted time

cdhowie  you are new and seem to be a troll

last week don't mean ??? to this week
last week was good this week ??? so what
you missed the point
its all LUCK period

how can you base an efficiency on luck
such an efficiency means NOTHING

Hi miners  ;)

I have a question.
How do I know if I have found the block?

For now, couple days, Im mining solo, but Im thinking about pool.

I did not say invalid, I said statistically insignificant.  You are drawing huge conclusions from a very, very tiny set of sample data.  If I flip an evenly-weighted coin and it comes up heads 20 times out of 25, that doesn't mean that the probability for heads to come up on every flip is 4/5.  It means I got lucky.  (Or unlucky, depending on whether heads is a good thing or not.)  As the number of coin flips approaches infinity, the ratio of flips that resulted in heads to total flips will approach 1/2.  The same principle is at play here.

Yup, exactly.

If you are mining solo, you'll know when you have 50 BTC in your wallet out of nowhere.  :)

If you are mining in a pool, that information may be tracked.  It is on bitcoinpool and slush's pool; others probably show this data somewhere too.

it will show you in bitcoin client... How many Mh/s do you have? if you are under 2000 Mh/s, it is usually wise to stay in a pool

Oh, usually I have 165Mhp/s  ???

go pool then LOL

Thank you, probably I will go :)

This should be "-v -w 128" or "-v -w128" without quote of course?


Also, can enybady tell me what is this?

http://gyazo.com/03045c43c8d83c357515fbff57d555fa.png

The number of confirmations of a transaction is exactly how many blocks deep it is in the block chain, with 1 being the current block, 2 being the current block's parent, etc.  The higher the number, the deeper the transaction is embedded in the network's collective history.  A transaction with six confirmations is considered fully confirmed.

The number of connections is simply the number of other Bitcoin nodes you are connected to.  You receive blocks from them, send blocks to them (if you successfully generate one), and send/receive transactions to/from them.

Apparently, FairUser and Geebus temporarily stopped all payouts because the hacker was changing users' payment addresses.

Any detailed info about what happen? SQL injection, XSS, social engineering or what?

Posted by Geebus on their forum:

1) russian federation/czech republic (you know Europe is one big country :) , and why not China ?
2) We originally stored everything in plaintext
3) essentially hex encoded SQL statements  

 :-X

LOOOOOOOOOOOL

No, I'm not the attacker (I'm from CZ) and believe that Tycho (Russia) isn't, too.

hmmm joint effort from tycho and slush to eliminate the no fee competition?  :D

it is quite a coincidence though  :P

I don't want to evolve any kind of conspiration theory, but saying "attacker was from Czech Republic or Russia" has similar weight as "attacker was from USA or Chile, because I know two guys from those countries who may be interested in hurting my little baby". IP ranges, provider companies, language or whatever is completely different in CZ and Russia. Czech Rep was former Soviet union, but it is more than 20 years ago. I'm quite interested in evidence that attacker was from CZ _or_ Russia.

But not too much to register on bitcoinpool forum and ask there (pardon - troll there).

I should make a poll.... who is the troll, BobR or nster.... guess what the answer will be  ;)

HINT: http://bitcointalk.org/index.php?topic=4540.0 in case your are a, in their words, "dumb ass"


you make quite the argument

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=5

Some people aren't getting paid in certain blocks? I'm definitively stopping mining there! First "malicious attacks" against them and now they don't pay on certain blocks? too fishy for me

Yep  your a BIG JOKE

Have a nice day with your trolling

So people don't have to read the whole thread over there:



How in the world was one user not paid for one of the blocks?

I guess since they say it is beta I am not surprised, but I will say that I really like how they have all their information available and does not feel like a black box. I would bet things like this happen on other pools but  good luck tracking it down. They seem honest.

Regan: Trust but verify (if you can)

I like deepbit better as everything is in the open now with the history and stuff

Have to say that I had hard times with pool payouts, too, so I understand bitcoinpool troubles. Fortunately I'm excessive logging everything, so when bitcoind crashed during payouts (but json results for 'send' commands  were True), I had everything needed to reconstruct all accounts to consistent state.

Depends just on programmer's experience if he covered also very unlikely states of application and if he can recover crash without losing someone's money...

I can understand the pool messing up for an entire block or for like the last half of the block or something like that. But only one user out of the entire pool not getting paid for a block?

I guess my concern is that it feels like the problem is likely to be much more widespread than has been identified so far.

I appear to be missing payments for some blocks too, and have been in contact with the admins about it.  Unfortunately I don't log very much, so I don't have a lot of useful info to give them other than "my historical balance on your site is larger than my payout to date" but I suspect that it may have been the same block(s) that we didn't get paid for.

 I have been watching mine like a hawk since I started mining just over a week ago and haven't had any problems with payouts except for when they were frozen due to the attacks, and has been resolved.

 Being an admin. It's not really fair to hold DDOS attacks against them. The only reason it would be justified to hold the recent breach against them is if it was gross neglect (which I don't think it was). Even the best admins can't stop someone if they really want to get into a system.

here here I agree
lest we feed the trolls & their nonsense

Every significant pool faced massive DoS attack already. I think operators should be happy that their pool is significant enough that somebody is trying to shut it down :).


How so? I think that it's pretty easy to _hurt_ some system (for example by DoS), but full system hack it is pretty complicated when you keep some basic rules while programming.

Agreed




No doubt clients started out with someone, or a few people, hacking some code together and came up with a client. There's at least 1 example on here that I've seen of someone creating a from scratch client. Not many people start out writing their software from a security perspective. Most start out just to make something that works, then optimize it. Security is very often an after thought. Once the pools opened and people started using clients it's hard to change that. How many pool operators are willing to upset the status quo and change the security model of their pool and make people upgrade to a "Secure!" client. Mass conversions are hard when you know all the people involved, nevermind a loose association of people such as mining clients. Someone may be able to code a backward compatible security model into the server, but unless you force people to upgrade not all of them will, and as long as the old model still exists the problem will be there.


Unless you write every line of code yourself you are trusting other people to follow those rules to the level that you think they need to be followed, and many people's definitions vary (especially in the free/open source software community). Simple services can have hundreds of lines of code behind them. Even if all the rules and accepted practices are followed it doesn't mean that someone can't find a way to subvert them and create an exploit.

In their case it was a SQL. No matter which SQL server you are using, it's most likely that you wrote little, if any, code that is running on it. SQL query and security issues are constantly being found and addressed for every SQL vendor. SQL is a pretty big software app with a lot of lines of code and marketing is driven on speed. Very few SQL vendors care to advertise their security in depth unless you're Larry Ellison and willing to make a fool of yourself on stage then have Marketing scramble to CYA.

Secure and Security are precesses, not states.

Their issue was not with a vulnerability within their DB vendor, it was a SQL Injection problem. SQL Injection vulnerabilities are caused by websites not sanitizing their inputs. You can solve this with a singular change that is global to the entire website that simply places escape characters around any potentially dangerous characters in input strings. This is something that every web page should ALWAYS do. Many web platforms have an option to automatically do this for you.

http://imgs.xkcd.com/comics/exploits_of_a_mom.png

+1

That's why I introduced separate credentials for account and for workers. Sending plaintext credentials for full account access with getwork request is simply crazy (I mean this globally, I even don't know if bitcoinpool.com use the same password for account and for workers).

With separate credentials for getwork calls, things are quite safe. I don't know any significant type of attack which can be done by stolen getwork password.


Well, I don't have enough info, but most likely the attack was targeted to wrong escaping or handling of sql statements in application itself than exploiting some bug directly in sql server (probably mysql). Bitcoinpool is using native mysql binding for php (mysql_*) and escaping sql manually; it's pretty easy to make a mistake here.

Of course I didn't read complete software stack which I'm using, but you can avoid pretty much common mistakes with using well tested high-level libraries (like ORM, libraries for sanitizing input data, ...) than writing it by self. I read megabytes of source codes (mostly in PHP) from programmers who like to 'do everything under their control' (=don't use high level frameworks) and it's sometimes crazy how easily people are making huge holes to their systems :).

Miner clients code do not related to pool frontend and backend software in term of security.
Passwords and user from miner client used only for user identification for submitted share.
There is no one reason (besides laziness) for hold plain text passwords for user accounts, or reuse the same password and name for user account.


Actually all normal programmers do not use raw sql queries with unescaped input from end user at least 7 years (if not more).
Only very lazy or naive "programmers" continue use this shit.

If you are referring to, for example, PHP's magic_quotes options then -- NO.  Those kind of options should never, ever be trusted.  They are not locale-aware (and therefore still vulnerable to injection attacks in some circumstances) and can corrupt your data if you're not careful.

Additionally, this would be the wrong place to perform such sanitation.  You should sanitize and escape values before they are used in whatever context you are using them.  For example, magic_quotes will protect against some (yes, some, not all!) SQL injection attacks.  But it will not stop XSS or the like.  SQL-escape user data before it enters the DB, not before it enters the entire script.  HTML-escape user data before you render it to a browser.  Etc.

A better option would be to use parametrized queries, which are by definition invulnerable to SQL injection attacks if the DB itself supports them, since the parameters are sent after the query has already been parsed.

Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS.

It does, via mysql_stmt_prepare() (http://dev.mysql.com/doc/refman/5.0/en/mysql-stmt-prepare.html), mysql_stmt_bind_param() (http://dev.mysql.com/doc/refman/5.0/en/mysql-stmt-bind-param.html), and mysql_stmt_execute() (http://dev.mysql.com/doc/refman/5.0/en/mysql-stmt-execute.html).  The basic steps are: prepare the query (this is where the query itself is parsed), bind the parameters you take in the query, then execute the query.  This illustrates that the user-supplied data is sent to the server after the query structure is known, thereby preventing all forms of SQL injection.  (But not ensuring data integrity, of course.)

That's useful, thanks.  I was looking at this page (http://dev.mysql.com/doc/refman/5.0/en/c-api-functions.html), and assumed that the "C API Function Descriptions" was a full and comprehensive list.

I use bound params with sqlite and postgresql already, but [mistakenly] thought mysql lacked same.

/me goes to update his just-written code...

Anything posted in this thread, by anyone other than myself or FairUser should be considered pure speculation or heresay.

We opened our own forum to address issues on our pool and from this point forward, we will not participate in any discussion posted to this forum.

You can join our forum at http://www.bitcoinpool.com/forum (http://www.bitcoinpool.com/forum)

And a note to slush... Unless you've audited our site through attempted attacks, or looked at our code directly through successful attacks, you don't know how our site, or pool is coded, and should not comment on it.

A FairUser post from BitcoinPool's forum: (emphasis added)


From the first portion's (2), it is apparent that FairUser still does not understand probability when it comes to mining. Either that, or he is purposefully spinning things to seem bad. Not finding a valid solution does not have any effect upon the probability of when you will find a valid solution.

And the 2nd part...... That's a great way to treat people that are contributing to you. What was that about gift horses and mouths?

Our pool. Our rules.

It seems you don't understand that.

I saw part of pool sources, as I wrote many weeks ago to the forum thread...


...but I didn't hacked your pool. Those sources were just printed on the homepage for some time (following block is reformated, but code untouched):


From this code I see that you were using mysql and inserting parameters directly into sql statements. So no black magic from my side, no speculations. And if you read carefully my previous post, I'm not attacking you, just thinking about possible problems.


As you see, I can read your code even without attacking your site :).

Edit: I'm just chatting with others about technical stuff, security and so on, it isn't targeted against you anyhow (I'm pretty tired that you take everything personally). And as I don't expect your reaction, I'm not writing it to official bitcoinpool thread.

Edit2: I published the code because I expect it is no longer in production. Looks like you followed my advice (https://www.bitcoin.org/smf/index.php?topic=4291.msg65704#msg65704) and removed the mysql_num_rows(mysql_query()) stuff, because pool homepage is little faster even on long rounds...

I do understand that. That's one of the reasons that I'm not registered on your forum.

This isn't your thread, therefore your rules don't apply.

Thats old code that hasn't been in place for some time slush. Likewise, not really capable of doing sql injection if no variables are being requested from other functions or from post data, so it's completely safe to pass a static variable to a SQL string without escaping it. Especially if I'm enforcing strict data types on the sql server.

Furthermore, the PHP code used to calculate pool hash speed is hardly an indicator of how the rest of our pool and site is coded.

Well of 349 get works so far 143 had no results
that's better than 1/3 that were worthless to hash to the last bit
these numbers are from poclbm-mod which continues running even now and has been running since yesterday on at least 5 different blocks

still  only  seeing like 1 in 8 above 75%

and FYI
after 4 days of excluded low efficiency's  the pool efficiency is still around 80%

Why do you use this pool if all you do is complain about it?

He troll and likes to call other people trolls. :p

Still, it is better to criticize a system and try to find potential flaws then leave it be and see many people getting ripped off by the said system unknowingly

You yourself said that the problem was injection.

I just making reports
trolls here are deciding what's real & whats troll turds "NOT  ME"
do as you will ...  WHO CARES
anyway

Today was not very different
I restarted /  re did for a previous version of sdk
was just an exercise in useless shit SDK 2.1 made no diff to SDK 2.3
saw NOTHING different

as a note i did see an hr with nothing reported....10+ nothing to shows

but mining everything REALLY helps
Fyi I think i'm down coins since the eff limit even though THE NUMBERS say I'm more eff

So what does that say ???

oh ps
  even slush says ignore nster -- everyone knows he's a troll

bobR, there are 2 things I have to say:

#1 learn english. Your posts are not very clear or comprehensible

#2 slush was being sarcastic...

http://img.techpowerup.org/110408/Capture142.png (http://img.techpowerup.org/110408/Capture142.png)

The bitcoinpool miner is the only one that works with sdk 2.1 on win7 afaik, which is worth almost 4% more for me in increased hash rate (40mhash total more for me on dual 5970's).  I'm solo mining though....

bitcoinpool miner is normal m0mchil miner with some cosmetic changes in logging and network layer, but it does not affect hashrate. standard poclbm works for me on sdk2.1 and win7 without any problem...

really?  i posted a 50btc bounty in the poclbm thread a while back to whoever had a solution to sdk2.1 + 10.11 drivers with dual 5970's on win7 64bit and this miner was the only one that worked

EDIT: just fired up some other miners and noticed they all work now.... must be the 11.2 driver update.

Yeah it was the only miner that worked for me, 7 x64

Hey guys!

All day Earning have been showing this:

Unconfirmed:     N/A

So I have no idea how much I have earned.  I notice that I can't find any other account that does.  Is there a problem with the service?

I switched to Slush's for the moment; at least until I know that my earnings aren't flying away. 

According to posts on BitcoinPool's own forum, it appears that the missing payments issue is indeed more widespread than just the one single instance noticed before.

The user audaibnjad has so far tracked 2 more blocks for which is hasn't been properly paid.

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=26


Edit:

Also, it looks like the user accounts are getting (successfully) brute forced or dictionary attacked and they haven't put in any lockout measures or other some such to prevent it.


Edit2:

Also, more concerns from users that are seeing the tell-tale signs that the pool is being attacked by implementations of the pool-hopping exploit.

In the interest of being objective, Geebus posted that this is due to blocks being invalid and not passing confirmation. This should also fix the discrepancy in the historical payouts.

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=27


When I was mining there, the speed would fluctuate through out the whole block quite a bit. It looked like people would hop on and request a few getworks, hardly process any, then drop off. A quick check of the user list doesn't show an active user or registered user with that name (subjective as it is) and smells like baiting to me.

Geebus hadn't found the issue yet when I posted about it.

But what Geebus found is also very interesting... Out of the last 50 blocks that the pool has found, 4 of them have been invalid.

That's an 8% invalid rate over the past 50 blocks!  :o

In the mean time (during basically the same time period), Slush's pool has only had 2 invalid blocks out of the past 500 (0.4%). And Tycho's pool pays 48.5BTC for each block found even if it is eventually found to be invalid.

If they are working on a block and there are 2 other pools that are 5x and 8x faster than them, then that wouldn't exactly surprise me. One of the other pools comes ripping through and finds the solution right before bitcoinpool doesn't seem that far fetched.

That's not how it works.

Invalid blocks are a function of how far away (from an average node distance standpoint) the pool's bitcoind is from the rest of the bitcoin network. A high number of invalid block submissions implies that the bitcoind instance is relatively closer to an edge of the network than the center.

The pool is working on a block with a prevhash pointing to the previous found block. But if the pool's bitcoind doesn't have the latest information from the blockchain, then it will be working against the wrong prevhash. The further away the pool is from the center of the network, the longer it will take (on average) for the pool to get blockchain updates.

Ok, that makes sense.

How can you be closer of farther away to the center of a distributed p2p network if there's no central node to connect to? lol

If their client is too far from 'center' how could that be improved? Is there a polling time that can be increased or something?

The "center" (there can actually be multiple centers if there are bottlenecks...) is the general area of the network that is most tightly connected with the highest number of other nodes. Think of it like The 6 Degrees of Kevin Bacon. There is actually a whole new area of math and networking theory that has grown around this. In the Kevin Bacon game, there are certain actors that have been in a LOT of movies (those nodes have a lot of connections to other nodes). This makes them very close (from a network distance standpoint) to Kevin Bacon and thus are centers of activity (hubs) for the game. But there are other people that may have only ever had one role in some really obscure movie. This person has very few connections and thus is on an edge. The more hops that it takes to get from any one node to a major hub is in general (there could be bottlenecks between hubs) the distance that needs to be surmounted in order to obtain updates.


There are known de-facto hub nodes running that you can try and get your node to connect to or close to. The next best thing (actually the best thing for the strength of the network) is to make sure that your (and the pool's) bitcoind node isn't behind a firewall and can connect to as many other nodes as possible. The more connections you have, the more likely that one of those connections will be close to a hub.

It's all about how many other nodes in the network you are connected to.  This is why it's a P2P network, kinda like torrents.  The more peers you have, the faster you get information. ;)
Currently bitcoin is set to 8 max outbound connections, and 125 inbound connections - MAX_OUTBOUND_CONNECTIONS.
Let's explain with the code itself.

Line 7:net.cpp

This means the maximum number of OUTBOUND connections (from you to someone else) is 8.  If you want your bitcoind to connect to more than 8 nodes in the network (which isn't that much), then change this number to something higher than 8.  I use 1000.

Line 710:net.cpp
This means the max number of inbound connections you can have is the "-maxconnections" option (which defaults to 125) minus the MAX_OUTBOUND_CONNECTIONS (which is 8 by default).  By default, you can have 8 outbound (from you to others) connections and 117 Inbound (from others to you) connections.  Inbound connections don't work if you're behind a firewall and haven't setup port forwarding or access to port 8333.

Line 1132-1133:net.cpp
This is choosing the smaller number between MAX_OUTBOUND_CONNECTIONS and the "-maxconnections" command line argument, and uses that number for the maximum number of outbound connections.  This would be 8.

So here's the changes I made for the colo server.
Line 7:net.cpp


Line 710:net.cpp

I also removed line 1133 entirely.

Right now the bitcoind on the server has 256 connections to others nodes in the bitcoin network. I intentionally kept this at 256 connections.  1 of those connections is to a server in a colo that was modified to have 1000 max connections. The colo server currently has 923 connections, and an uptime of 53 days.

I would say we are very, very well connected to the bitcoin network.  If nobody else is doing this, then we might be the node with the most connections in the bitcoin network.  ;D It's probably not a good idea for everyone to do this, but since I run a pool, I want to be as well connected to the bitcoin network as possible.

You'll probably be interested to know that slush thinks this is a good idea too.  I mentioned it to him several months ago.



I'm not submitting an official patch because if everyone did this the network would get very, very active with the same information being broadcast through out the entire bitcoin network several hundred times.

So back to the point, we just got unlucky with our blocks.  Someone else got a better fit answer for the block so the pool didn't get paid, and that's why everyone else didn't get paid.  We had code in place to catch when this happens, but we found the typo which caused it to not execute properly.  As a result invalid blocks were being treated as valid, which is also the reason everyone's historical earnings were off.  We have gone back through and marked the invalid blocks as invalid, and fixed the historical earnings at the same time.

Gotta love them bugs.

Firstly, I see pretty unfair that you're publishing our private communication for your own defense.

Secondly, this is 3 months old message and I learned a lot of things in meantime. My Pool is currently connected to ~100 other nodes, but I connect manually to some well known and well connected hubs. In last 400 blocks where I did some improvements, I didn't hit single failed block.

So I think that 8% is really pretty high invalid ratio. Just for curiosity - how long time takes the processing of block broadcasts? I think that there might be some hidden problem behind your custom patches. It's no offense, I'm just thinking aloud.

I also want to reinforce that most people should not follow FairUser's example.  We don't need every client out there connecting to 1,000 nodes.

Mathematically, you don't need anywhere near that many.

++
It's not for everyone.

What happened?
Pool speed is 0ghash/s. Confirms table is broken.

http://bitcoinpool.com/account.php

the account login page is borked....

I agree. It is. Come on guys get it fixed. ;)

I believe they are watching their own site forum.  Looks like someone else brought it up and they replied to them.
http://bitcoinpool.com/forum/viewtopic.php?f=1&t=32&p=262#p262

Interesting Note: The company I work for just moved my office over to their proxy and now bitcoinpool.com is being blocked under the reason of "Games". I haven't found any other bitcoin related cites that I visit that have been blocked.

I assume it's due to "pool" - might be worth checking Bitcoin Darts (http://bitcoindarts.movoda.net/)! :-)

Yes, they are also blocking bitcoindarts.

If it is Websense...

Bitcoinpool.com is Uncategorized
deepbit.net is Uncategorized
mining.bitcoin.cz is categorized as Information Technology
bitcoindarts.movoda.net is categorized as Games
BTCmine is Uncategorized

I can't tell what it is (websense vs others) because they have completely stripped it down to just displaying the category being blocked.

Hello to geebus or fairuser it seems there was a problem with my miner last night it's not generating but still requesting getworks.  Feel free to disable me I'm not at home for the holidays.

Feel free to post on their forums (or PM them directly) if you're a member of their pool. They reply pretty quickly there and give clear statements as to what has caused any known issues and what they are doing to resolve them.

I thought I would drop in and let people know that our pool has resumed normal functionality.  We got hit pretty hard yesterday with a DoS attack, but we've been able to muffle it for the time being.

I would also like to point out that just because we had some problems with the site yesterday, we still found 7 blocks and users have been paid for the blocks that are now confirmed.

Thank you all for your understanding and participation.

BitcoinPool has been getting Hacked and DOS'd fairly successfully and quite constantly for the past 2 months. That's a horrible thing to do to any service provider. But, now it looks like BitcoinPool's owners are thinking about going and hacking other people in response.


FairUser said he doesn't want to point fingers because he doesn't have proof, but as has been shown earlier in this thread, he's already pointed fingers at both Slush and Tycho with "evidence" that doesn't even actually point to them (the IP Addresses posted in some of their earlier posts about the hacks do point to Eastern Europe, but not to where Slush is).


And now FairUser is openly accusing Slush without posting any evidence at all. He says that he's been able to figure it out from comments posted on the forums, but I haven't seen a single post from Slush that would indicate that he is hacking/DOSing them.

I'm not trying to defend Slush here. I have no idea what he does or does not actually do. But, if you are going to openly accuse any member of this forum of illegal activities, then provide your proof.



Edit:

Also, FairUser was saying that Pool Hopping doesn't actually work at all, but they put in an anti-pool-hopping measure.... One that works in a conceptually similar way to scoring (making earlier shares in a round worth less) even though they said that they would never do something like that.

It is difficult to believe that anyone would do business with this pool.  All you have to do is review a couple of their posts to see how juvenile and unprofessional they are.  Avoid!

Wow, whereas if you speak to the people in the pool you'll find that they are more than happy with the time and effort Geebus and Fairuser put in to make the pool a success. What's funny it that I've noticed hostility in this forum from the day they started, it's almost like certain people are opposed to a 0% fee pool.

A for Xenon's post, a discussion is just that, a discussion, and that's all Fairuser and Geebus can be accused of so far. Are you going to berate the attacks or spend more effort berating the person being attacked who has asked his users what they think he should do next? If you ask me, your post is  biased against the person being attacked, even though you've made a vain effort to appear neutral to anyone reading it. Does this mean that you secretly condone other people attacking pools that you don't personally like?

The only people who seem to dislike, distrust, or belittle our pool are those who haven't tried it themselves.

This is about the most laughable post I've read on this forum so far.  And I've read some of bobR's stuff...

Upset because we banned you for being inefficient?

It's a rule. You broke it.

We don't ask much, we don't expect much. Shit, God had 10 commandments...  ;)

What?  I left the pool voluntarily; my account was in good standing with over 90% efficiency.  If anything, it got banned for inactivity.  It might be a good idea to get your facts straight.

I haven't been able to reach www.bitcoinpool.com for over a month. I didn't even know it still existed, but I just tried with a proxy and it works fine, so it looks like your site is randomly ip banning people.

Our logs show otherwise, but either way, the last time you even participated in the pool was over a month ago and a considerable amount (http://www.bitcoinpool.com/forum/viewtopic.php?f=7&t=70#p419) has changed since then.

We banned a large number of IPs that were attempting various attacks against the pool.

This statement underlines the reason I decided to stop doing business with you.  There are a limited number of possibilities here.  You are either: lying, unable to tell what is true (logically incompetent), or, based on the incorrect logs, unable to write solid code (technically incompetent).  I'm sorry, but I do not trust my money with someone possessing any of these qualities.

I'm too much busy to care about your pool, my friend. I never tried anything with your pool. No hoping, no DDoS, no breaking passwords. I'm really interested in your evidence, because you're talking bullshits. I totally don't understand why you hate me so much.



Oh my god, why? I don't care about you at all.


My god, how is this related to DDoS, password breaking and all other shits? I wrote you that *if* I'll try pool hoping, I'll do it in open way, as real proof, not because I want to earn bitcoins.

Please, ignore me, right? And please stop saying that I'm an attacker without any evidence. Btw I was (probably) attacked during this weekend, too. There is somebody trying to shut down some important bitcoin services (like mtgox and, ehm, me). Why are you so sure that *I* am the attacker?

It's possible that you left around the same time that we starting logging each ban independently based on reason and your ban was mis-categorized. I didn't say you were wrong, I said our logs showed otherwise, stating, in hand, that upon inspecting your account history and our logs, it showed that you were banned for low efficiency. A lot of those logs were recategorized by hand when we first implemented the system. It says nothing about the rest of the pool functionality or code, nothing about my ability to be logically competent, and doesn't say that I'm lying either.

It only says that my logs differ from your stated comment. However, if you choose to read that far into it, I can into you saying that by choosing to leave a pool that has no fees, consistently improves and implements new features, and grows on a daily basis in favor of any of the other options that were available a month ago, you're displaying that you personally are not capable of doing basic math in regard to net gains, as is the case with the better portion of the bitcoin community, as they left one pool that charges excess fees for another that charges even more.   

My account was compromised & it was never mentioned to me.
I daily checking bitcoinpool.com & it displayed compromised account & my account never listed, so done nothing.
I mined yesterday & got 2 transactions in my email showing that

Amount: 0.2062528 & Amount: 0.07712649
Recipient: dishwara [1DML7p6LJG3QKo169Zga2iCP9Yn4Qvxdyg]
transfered. I keep on checking bitcoin client , nothing is happening, checked in block explorer coins transferred, then checked my address book, that address was not my address at all.
the FUCKING BASTARD, hacked my account & changed my bitcoin address, so that i lost 0.277 coins with out changing the password.

GEEBUS & FAIRUSER ALERT ALL YOUR MEMBERS TO CHECK THEIR BITCOIN ADDRESS IN THEIR ACCOUNT IS SAME AS THEY GIVEN & ALSO ASK TO CHANGE PASSWORD IMMEDIATELY.
Also, always the password typed in your sites goes unencrypted which makes any one to hack account.
SaferChrome Extension for chrome always shows in RED, password box meaning, it is not safe.


To the BASTARD who own this address 1DML7p6LJG3QKo169Zga2iCP9Yn4Qvxdyg, I am 100% sure & also this world knows now that, your mom & your daughter sucked & fucked me for that bitcoins, enjoy u PIMP.

We posted numerous times to all of our users when the original attack happened on April 15th to change their passwords. If you didn't do it because your name wasn't on a list, thats your own fault.

Its not my fault, i am not asking you to pay me.
You seems not understanding still.
They didn't change password, they changed ADDRESS.
Since Bitcoin address is not a number very very very very easy to remember, it is very hard to find whether it is changed or not.
The hacker hacked members account & changed the address, so that he gets bitcoins, not members.
This is not about password only, its about ADDRESS also & address is very very very very important than password here in bitcoin world.

The email i received from you only tells to change password, not saying anything about address checking, verifying & confirming.

People were told to check their wallet IDs and the pool owners halted all payments for a couple of days to allow compromised accounts to check their payment address, thus preventing payment to any changed accounts. 5th post quoted from bitcoinpool forum thread that was linked in large red text on the front page:


The pool owners have worked very hard to try and ensure that they and all pool users update and secure their accounts after the initial attack.

While I don't trust bitcoinpool operators at all, this is true, they did say to check wallet addresses

Fair enough.  The logs are simply wrong.  However, let me return to the point I was trying to make (and that you seem to only be helping me make):

This is a demonstrably false wide-sweeping statement.  I am one counter-example; there are likely others.  It's best to avoid making categorical statements of the form "All S are P" unless you can prove it.

A rush to judgement, using data generated from code that you have since admitted you knew to be buggy.

Now, to return to your latest reply:

You're right there.  But this combined with the SQL injection vulnerability that was already exploited only furthers my case for avoiding your pool.  Where there's smoke...

The pool I'm in takes a flat fee of 0.02592 BTC from the entire pool per 30 days, which is less than 0.01 BTC when you consider that it is divided among all workers.  Again, you rush to judgement without getting your facts straight.  I don't think I can make my point any better than you already have.

Seeing everyone was aware of the "breakin / hacking"
Just who is to blame for not checking your account's accuracy?
How are The pool operators supposed to know what your bit coin address should be ??

I think even if they didn't say to you would change your password and make sure the coins were going to your account knowing that someone else's accounts had been compromised.

Seems, victim is to get punishment.
dishrag cleans mess created by others & it doesn't create mess.
I apologizes to the bitcoinpool.com & their members that it is/was my fault for not checking out my account with correct password & wallet id.
Instead of checking my account & securing myself i made an accusation that made many members time, money wasted & also created unnecessary problems.

I deeply from my heart apologize to all the members for creating a mess, instead of solving it myself.
Sorry.

I've been using this pool for a day and just received my first payout.  So I thought I'd post my experience.

1) So far the payout seems to be in line with my expectations.

2) Uptime isn't perfect, but it's good enough.  No complaints considering all the DDOSsing going around.

3) I don't really get the controversy over the efficiency issue.  This is an entirely reasonable thing for a pool to encourage.

4) I am concerned about the pool hopping issue.  But the proposed solution seems reasonable and effective.

5) The website isn't great.  It's impossible to navigate.  Why are the stats on the front page?  It took me almost a day to figure out what the statistics meant.  Estimated payouts are wildly inaccurate.  Since I joined at the end of a block, for the first few hours I was convinced I had hit some kind of Bitcoin jackpot.  Alas, that was not the case.

6) Not encrypting passwords is dumb and will likely end up being a dealbreaker for my continued use.

It's nice when the sub-1hr blocks hit, especially 2 in a row. There is still the occasional 16-24 hour block so it still evens out.


With phoenix becoming really popular and managing it's own work queue and other miners improving other pools are going to see some efficiency gains whether they agree with the argument or not.


From what I have seen so far pool speed stays pretty consistent until the 6 hour mark then a lot of people hop out. Since there's not a graph of speed/round time or json data for the pool you can't be sure, but I end up checking it a lot and don't see a lot of big changes in within average round times.


They wanted to be as open as possible with the data, so it's right out front. Estimated payouts are (your submitted shares/total submitted shares), they vary a lot at the beginning of the round. I don't see mine vary that much after the round has been going for a while.


This was fixed over a week (or two) ago now. I never had a problem with my account. I changed the password once after the compromise, and change it occasionally for good measure, and check to make sure my address hasn't changed occasionally also. It's really not that big of a deal for me.

Happy Mining

I was actually referring to encryption of the account login page.

But I have some more concerns with the stats.  Errors like this one make me wonder whether shares are being calculated correctly.

http://imagepaste.nullnetwork.net/img/1305406489Screenshot.png

Also, poclbm-mod shows my hashrate as at least 300 Mh/s every time I look, yet my account page varies wildly and is regularly as low as 200 Mh/s.  What is the explanation for this?

well their efficiency  bs is starting to take toll
with increased difficulty and Long poll  they no longer tolerate cpu miners or any slow gpu's
they just want the fast ...  and those that can't see what they do

how the He.. is mining every list bit of a get work efficient for the miner
continue hashing on bad getworks or those with no reward

and then deal with fifth grad math math skills
oh it's a mistake
excuses & down right lies ... well it will get better
abuse from the ... people in charge
they do little more than bad mouth anyone the has the BALLS to speak up
guess what it's not better it got BAD

after 2 months ...  may they do well

oh we give stuff away for the screw job we give .. more promises
do we lie & fU ...dua

To be correct - yes, this is possible. There can be more valid responses for one getwork request.

They have abandoned poclbm-mod in favor of phoenix.

Okay I see that now.  That makes sense.

Any insight on the hashrate issue?  I ran a log for several minutes and it shows an average of 320 Mh/s.  The website shows something around 250 Mh/s.  I can't be the only one to notice this.

Remind me again why lots of other miners have adopted the same idea and tried to increase efficiency if it's BS?

Every site does that. The site is not in direct contact with the mining client as to how fast it is processing, so it uses math to try to make a guess on depending how fast you submit results. If you submit a few valid responses at a time it looks like you are submitting more than the average speed of the client so the math says you're faster than you are.

I just looked at mine and the site was reporting 2/3 of my total speed. I looked at my client output and there were 4 long polling updates within 30 seconds of each other. So the miner dumps it's queue each time and grabs new data, processes 1 or 2 getworks then gets told to dump them again. So it processed less getworks during that time than average and showed a slower speed on the website.

Wouldn't you say that's kind of a huge efficiency hit (1/3)?  I consistently see values that are 1/4 less than what my local client shows.  Isn't the value on the website an average (over 5 min)?

The B.S. part is his attitude and how he bans just about any CPU miner. Statistically speaking there is no good reason for worrying about "efficiency".

That's speed, not efficiency. If you are seeing values that low try restarting your client(s). I'm seeing an unusually high "queue empty, miner idle" messages on my phoenix clients, could be bitcoinpool getting hit really hard with ddos today or something going on in the system.

The average is supposed to be 5 minutes, yes. I saw the same swings both ways on all sites that I have been on, I have been on 3 different sites in the past 2 months.

They believe that there is a reason to worry about efficiency and that is what their site is based on. Since efficiency is their goal and cpu miners are horribly inefficient they are within their rights to not want or allow them there. If you used a client that let you set the askrate so that it fulfilled the efficiency requirement they would probably allow it to run on their site.

I do agree that it's within their right to ban whoever they want. But, nevertheless, it seems rather silly on their part to ban CPU miners under the cloak of "efficiency" when (other than the # of getwork requests) 100 CPU miners at 800 kilohash/sec is roughly identical to 1 GPU miner at 80 megahash/sec.

Just sounds like he's turning down free money to me. But, to each their own.

A $100 video card will get you 350 MH/s, so by your maths it will take 420 CPU miners to equal one GPU miner. The GPU miner will be running at 90% efficiency, whereas the slow speed of the CPU will make it worse. This means that 420 CPU miners will have a lot less accepted blocks than 1 GPU miner. The idea of bitcoinpool is that they try to make every block count.

Before I bought video cards I put my CPU on there and watched it and it was terrible. It was grabbing up a lot of getworks that it was never going to process through. After about a half hour I just shut it down because it was ugly.

80 MH sounds pretty small compared to the size of the smallest pools and easily done with a low end graphics card. If that was coming from 1 person that wanted to try it and could tune the efficiency to meet the requirements then it might be worth it to them. Trying to manage 100 clients at 800 kH/s would be not be a advantageous unless there was a miner that managed cpu efficiency for them like the new generation of gpu miners are doing.  

And... explain to me how turning away free workers makes "every block count"?

Perhaps their network connection is limited.

It doesn't take much bandwidth to maintain a client. I think I saw somewhere tyco said something like 10 kb/s per client. The issue is that cpu miners are fractions slower than gpu's and if they are requesting work at the same rate then they are eating up valid getworks and never processing through them all.

Correct on the getwork requests being small.

However, if BitcoinPool is implement so that every client is operating off the same private key, then this is a failure with the way they implemented their pool.

If every client is operating on their own private key (which, by "their own" I mean one generated for them and known only by BitcoinPool), then they would never have this problem you are speaking of.

In addition to nonce, the hash varies based on timestamp and private key (already discussed). So, in theory, every second a new "address space" (as you've called it) opens up. Not to mention, if every client IS operating off the same private key, then they are duplicating efforts. The miner client picks their nonce range, not the pool.

My guess is that they do use multiple private keys.

This is not true. Period. MHash/sec is MHash/sec. It doesn't matter how many clients it required to do that. It doesn't matter how many getworks. It especially doesn't matter how far into the getwork a client processes before starting a new one. Over time, they will ALL find the same number of solutions per MHash/sec in the same time period.


No, the idea of bitcoinpool's "efficiency" is to reduce the amount of server processing and bandwidth load.  This load is absolutely minimal.

Before Long Polling came around, working the entire getwork was idiotic because of the increase in stale shares (especially for a CPU miner!), but now that most of the pools support Long Polling, there is no reason for the miners not to reduce the server load in this manner.

But doing so does absolutely nothing for the miner and DOES NOT increase the number of shares that you find.

Thank you, thats what I've been trying to say all morning :D

Could some please tell me what an acceptable efficeincy figure is for this pool? I've just started and I am currently at about 65% and I fear this may be too low.

Is there a way to increase my efficeincy with GUI miner? I know it is recommended to use pheonix but I currently do not have the time or sufficient knowledge to setup this up. I know the information is out there to do it but my keyboard doesn't have a working forward slash key at the moment which makes command lines impossible. I could probably tie it to another key in some way but I dont know how. To find out just further adds to the time issue.

I will eventually move to pheonix as it seems to produce better figures but for now I need to make do with GUI miner.

I think the lower limit is somewhere around 60%, I'm not absolutely sure though. You can ask on the bitcoinpool.com/forum though.

I did go over there but some sort of error came up when I tried to use the search function. I'll go have another look.

They say 30% but they are pricks and do what they please
They change their mind as frequently as I take a leak
and now they take half of anyone that they deem by their determination to be pool hopping
so much for FREE ... no fee

FYI spent the $10 and get a keyboard

Well if by "do what they please" you mean "enforce the 30% rule", by "change their mind as frequently as I take a leak" you mean "announce all rule changes, which are infrequent, clearly in the pool news subsection of their forums", and by "now they take half of anyone that they deem by their determination to be pool hopping" you mean "take half, of which half is re-distributed back into the pool, from people who participate in less than 50% of a given round as determined by their first and last submitted shares, which is actually more fair to non-dedicated miners than a score-based system", then I agree with you completely.

[Citation needed]  :)
From what I can read on their forum, they don't seem to redistribute those shares:

"I did change the code so that in the event of a long round (6 hours or more) then the way shares are redistributed changes. Instead of cutting each pool hopping users by half, and then distributing 1/2 of that remainder to both FairUser and Myself, it will distribute 1/4 to both FairUser and Myself, and then remove the remaining 1/4 of the shares from the round. This will cause everyone else's share value to increase."

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=103&start=40

4th post on the page.  In all fairness I did have it slightly wrong as 1/4 of the shares are eliminated as opposed to being redistributed back into the pool, but it has more or less the same effect in terms of how much they are taking and how the rest of the pool is affected.  Also,  it's not like they are just pocketing that cash: http://www.bitcoinpool.com/forum/viewtopic.php?f=7&t=125
 

I see.
Thanks for this clarification.

Is this pool down?

It's down for me, at the moment, which is a shame, as I was still playing with their new website..

Down for me too.

From bitcoinpool.com

Once again, the owners of this pool make factually incorrect statements in order to promote fear, uncertainty, and doubt.


What the pool owners call "efficiency" (server load) has absolutely no relationship with how many blocks-per-day the pool finds. The reason for the same number of blocks-per-day is because difficulty has gone up.


That doesn't matter one single bit. The odds of you finding a block are the exact same no matter if you complete that getwork or if you ask for a new one.

Looks like bitcoinpool.com may be dead finally. Looks like they've found two blocks in the last three months and haven't paid out on either of them. According to their forum sigs, the admins aren't even mining there anymore and no one is responding to forum posts asking about the status of payment.

They are well-reputed enough and ran the pool long enough that I'm not accusing them of taking the money and running, but it does look like they've gone home and aren't bothering with keeping the pool alive anymore. It might be best if they'd stop accepting miners' hashes if they aren't going to bother paying out.