As I promised, I just sent 3 BTC to you (GPF not a shop, but I like them). Looking forward their shop accepting bitcoins, I'll send next 3 BTC... |
|
|
|
Why do you track users for google?
Because I'm curious how many people is going to the site? |
|
|
|
Unless you've audited our site
I saw part of pool sources, as I wrote many weeks ago to the forum thread... through attempted attacks
...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): // GHash/s
$numshares = mysql_num_rows(mysql_query("SELECT username FROM shares"));
$sampletime = 300;
$deltaframe = time() - $sampletime;
$sharesbeforedelta=mysql_num_rows(mysql_query("SELECT username FROM shares WHERE datetime < '".$deltaframe."'"));
$sharesdelta = (($numshares - $sharesbeforedelta) * pow(2, 32)) / $sampletime;
while(strlen($sharesdelta) > 4){
if(strlen($sharesdelta) >= 10 ? $sharesdelta = ($sharesdelta / 1000) : $sharesdelta = $sharesdelta);
if(strlen(round($sharesdelta)) >= 7 ? $sharesdelta = ($sharesdelta / 1000) : $sharesdelta = $sharesdelta);
if(strlen(round($sharesdelta)) >= 4 ? $sharesdelta = ($sharesdelta / 1000) : $sharesdelta = $sharesdelta);
$sharesdelta = round($sharesdelta, 2);
if($sampletime > 60 ? $avgstr = ($sampletime/60)."m avg" : $avgstr = ($sampletime)."s avg");
$theReturn = "Estimated Pool Speed (".$avgstr."): ".$sharesdelta." Ghash/s";
}
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. , 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.
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 and removed the mysql_num_rows(mysql_query()) stuff, because pool homepage is little faster even on long rounds... |
|
|
|
You did first metapool. It was just matter of the time, but still - congratz  Edit: Does this solve long polling somehow? |
|
|
|
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. 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 . |
|
|
|
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 . 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. |
|
|
|
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... |
|
|
|
Elliott Wave theory ... don't have much faith left in so called technical analysis at all.
isn't the only one TA tool on the planet. I personally think that EW is pretty complicated nonsense. I talked few guys trading EW and they didn't agree on many non-obvious patterns. I mean - it's such complicated that everybody see the waves which he want to see. I m a fundamentalist now.
Me too. That's the reason why I'm trading simple price action patterns . Usually the _real_ fundaments are traded by somebody before we get the information for ourselves (except we're the insiders). So I believe that price chart already contains everything needed to trade... |
|
|
|
In connection to recent security issues of other bitcoin site I want to clarify, that pool application does not store account passwords in paintext, but as hashes with random salt to avoid possible dictionary attacks. Also pool sources are built on technologies which does not allow SQL injection in any form. Finally, the profile page is using techniques against Cross site request forqery attack. It makes impossible to modify (for example) wallet address from malicious javascript. I care about overall pool security a lot. |
|
|
|
it is quite a coincidence though  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). |
|
|
|
Good to know who is receiving my fees (the block is full of pool payouts, it was before I started to use sendmany . |
|
|
|
We've also tracked the attacker to the russian federation/czech republic.
LOOOOOOOOOOOL No, I'm not the attacker (I'm from CZ) and believe that Tycho (Russia) isn't, too. |
|
|
|
hacker was changing users' payment addresses.
Any detailed info about what happen? SQL injection, XSS, social engineering or what? |
|
|
|
With your pool is it ok to "log in" or use the same worker login on the same machine? Or do you require that I create different workers for each GPU? I have a Radeon 5970 and naturally it has two GPUs so that's why I'm asking. At the moment I have two separate workers - 1 for each GPU.
You're doing it right - separate workers for every instance, as is mentioned on homepage  . As a suggestion maybe you can add a FAQ section on your website so stupid questions such as mine can be answered? :p
Yes, I have few points to faq written already, have to finish that and publish . |
|
|
|
OK that's pretty much what I was talking about then. So my stupidly small transaction at the moment won't be accepted by most miners, which means it wont get recorded in the block chain which means it wont happen, right?
Exactly. |
|
|
|
|
Oh sorry, I read it badly, you're talking about transactions, not about transaction fees.
|
|
|
|
High chance this person is a scammer, first posts of person are about making a large buy, preferably using paypal. Who wants to buy 10kUSD of bitcoin with little or no interaction with us previously.
I don't think so. He didn't mentioned paypal. And - why should anyone have long talks on this forum before big buy? There are busy people who don't want to spend hours on forum at all. This forum != all bitcoin users. People here around are calling investors. And when they arrive, people call them scammers? |
|
|
|
I understand that the network has set a limit on transaction size, the smallest being 0.01(right?), I know that smaller than this has been sent, but not recieved, where has it gone?
Afaik the fee under 0.01 is still received by miner, but such small fee does not improve transaction priority. |
|
|
|
Last 1000 blocks up to block 2872 on Slush's pool had 13 invalids or 1.3%.
It's 12 invalids, the #116884 was temporarily marked as invalid because I had to check its generation by self. Now it is valid and reward is distributed between workers. The largest determining factor in this discrepancy is that invalid blocks
I improved server infrastructure to process block distribution faster. Looks like it helped, last 150 blocks (where I made changes) are without single invalid block. Of course I didn't solved it 100%, some invalid blocks are normal, but the ratio should be much better. |
|
|
|
What's the situation with blocks such as #2861 in the "Block History" section of the BPM stats page where it shows "Block #" as 0 with an invalid blockexplorer.com link and lists the validity as "Confirmed" immediately? Is that a real block, or a bug, or something else? Is the reward for such blocks valid? Looks like bug, but I never see it before. Now I'm not at home so I marked the block as invalid manually. From blockexplorer it looks like the block is ours, but I have to search logs and see what exactly happen. If block is really ours, I'll mark it as valid and distribute the reward for it, of course. For some strange reason, the sql command which saves blocknum and block hash to database failed. But block 116884 was succesfully confirmed and is ours, so I fixed block record in database manually and marked it as valid. Reward will be distributed at 10:00 UTC. |
|
|
|
|
Show Posts
