Bitcoin Forum
December 09, 2016, 11:20:11 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 »  All
  Print  
Author Topic: BitcoinPool.com open thread  (Read 27628 times)
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 06, 2011, 08:05:38 PM
 #61

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

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

Quote from: dafishman
Actually, I've created a spreadsheet and tracked it down to two blocks that I have not received payment for. They are blocks 116105 and 116455. It would be nice if the site could show payment history per user per block. (Only under users login of course...) Although, I don't mind keeping my own books. I checked my wallet id's against block explorer and confirmed the transactions did not take place. Any help would be appreciated.

DaFish

Quote from: Geebus
I see that you were in fact not paid for block 116105, and I'll manually issue that payment to you.

However, for block 116455 I see the following in both our database, and bitcoin debug log:

Amount
2.56639874

Block
116455

UTC Timestamp
1301876564

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

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
1481325611
Hero Member
*
Offline Offline

Posts: 1481325611

View Profile Personal Message (Offline)

Ignore
1481325611
Reply with quote  #2

1481325611
Report to moderator
1481325611
Hero Member
*
Offline Offline

Posts: 1481325611

View Profile Personal Message (Offline)

Ignore
1481325611
Reply with quote  #2

1481325611
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
shackleford
Full Member
***
Offline Offline

Activity: 191


View Profile
April 06, 2011, 08:37:26 PM
 #62


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)
nster
Full Member
***
Offline Offline

Activity: 126



View Profile
April 06, 2011, 08:43:54 PM
 #63

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

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
April 06, 2011, 08:45:02 PM
 #64

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

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...

xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 06, 2011, 08:47:08 PM
 #65

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

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
cdhowie
Full Member
***
Offline Offline

Activity: 182



View Profile WWW
April 06, 2011, 08:48:29 PM
 #66

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.

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
April 06, 2011, 08:54:00 PM
 #67

 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.

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
bobR
Member
**
Offline Offline

Activity: 112


View Profile
April 06, 2011, 09:01:42 PM
 #68

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
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
April 06, 2011, 09:02:37 PM
 #69

It's not really fair to hold DDOS attacks against them.

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 Smiley.

Quote
Even the best admins can't stop someone if they really want to get into a system.

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.

grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
April 06, 2011, 09:32:31 PM
 #70

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 Smiley.

Agreed


Quote
We originally stored everything in plaintext for compatibility with some miners. This was also prior to us adding any account modification tools to the site.


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.

Quote
Even the best admins can't stop someone if they really want to get into a system.

Quote
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.

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.

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 06, 2011, 09:47:46 PM
 #71

SQL query and security issues are constantly being found and addressed for every SQL vendor.

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.


Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
bombo999
Member
**
Offline Offline

Activity: 107


View Profile
April 06, 2011, 09:55:58 PM
 #72

+1
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
April 06, 2011, 09:56:08 PM
 #73

Once the pools opened and people started using clients it's hard to change that.

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.

Quote
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.

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 Smiley.

dbitcoin
Hero Member
*****
Offline Offline

Activity: 742

BTCDig - mining pool


View Profile WWW
April 06, 2011, 10:08:41 PM
 #74

Quote
We originally stored everything in plaintext for compatibility with some miners. This was also prior to us adding any account modification tools to the site.


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.

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.

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.

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.

BTCDig - mining pool (Stratum, VarDiff, DGM, SSL, JSON API)
cdhowie
Full Member
***
Offline Offline

Activity: 182



View Profile WWW
April 06, 2011, 10:38:05 PM
 #75

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.
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.

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
April 06, 2011, 10:53:17 PM
 #76

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
cdhowie
Full Member
***
Offline Offline

Activity: 182



View Profile WWW
April 07, 2011, 12:03:58 AM
 #77

Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS.
It does, via mysql_stmt_prepare(), mysql_stmt_bind_param(), and mysql_stmt_execute().  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.)

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
April 07, 2011, 12:24:07 AM
 #78

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

That's useful, thanks.  I was looking at this page, 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.

* jgarzik goes to update his just-written code...

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
April 07, 2011, 12:43:21 AM
 #79

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

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
April 07, 2011, 12:43:37 AM
 #80

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

Quote from: FairUser
[...] If that 90% of the getwork you missed contained the answer for the block, chances are you will not (1) find it and (2) get another getwork that contains the answer for the block for several days.

It is in your best interest and the pools for you to be efficiently mining. Please fix your problems before you continue mining in this pool. If you have a problem with that, then go be inefficient in different pool (cause it helps us when you do ;-).

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?

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
Pages: « 1 2 3 [4] 5 6 7 8 9 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!