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.
Topic: BitcoinPool.com open thread - page 7. (Read 29840 times)
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?
Posted by Geebus on their forum:
Quote from: Geebus
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.
We're working on corrections to the system now to be more secure, and we've since closed the holes that the attacker was using to exploit (essentially hex encoded SQL statements that were overflowing and dumping table data).
We've also tracked the attacker to the russian federation/czech republic.
Our worry was that your wallet ID may have been changed via injection, and that the attacker may have seen your password, which would allow them to log into the account at a later time to change it [your wallet id] by hand.
We're working on corrections to the system now to be more secure, and we've since closed the holes that the attacker was using to exploit (essentially hex encoded SQL statements that were overflowing and dumping table data).
We've also tracked the attacker to the russian federation/czech republic.
Our worry was that your wallet ID may have been changed via injection, and that the attacker may have seen your password, which would allow them to log into the account at a later time to change it [your wallet id] by hand.
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
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:
Quote from: Geebus
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.
We're working on corrections to the system now to be more secure, and we've since closed the holes that the attacker was using to exploit (essentially hex encoded SQL statements that were overflowing and dumping table data).
We've also tracked the attacker to the russian federation/czech republic.
Our worry was that your wallet ID may have been changed via injection, and that the attacker may have seen your password, which would allow them to log into the account at a later time to change it [your wallet id] by hand.
We're working on corrections to the system now to be more secure, and we've since closed the holes that the attacker was using to exploit (essentially hex encoded SQL statements that were overflowing and dumping table data).
We've also tracked the attacker to the russian federation/czech republic.
Our worry was that your wallet ID may have been changed via injection, and that the attacker may have seen your password, which would allow them to log into the account at a later time to change it [your wallet id] by hand.
hacker was changing users' payment addresses.
Any detailed info about what happen? SQL injection, XSS, social engineering or what?
Any one notice
no payout since the last totally 120 confirms
no payout since the last totally 120 confirms
Apparently, FairUser and Geebus temporarily stopped all payouts because the hacker was changing users' payment addresses.
Also, can enybady tell me what is this?
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.
Quote
AMD 5xxx and up
use '-v -w 128' for better performances
use '-v -w 128' for better performances
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
go pool then LOL
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 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.
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
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 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.
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
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.
If you are mining solo, you'll know when you have 50 BTC in your wallet out of nowhere. How do I know if I have found the block?
For now, couple days, Im mining solo, but Im thinking about pool.
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.
And discounting a small sample
makes it invalid
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.makes it invalid
you missed the point
its all LUCK period
Yup, exactly. its all LUCK period
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 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.
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.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
That's not so say I haven't had a bad hour or two where I run a bunch of empty getworks. 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 weeklast week was good this week
so whatyou missed the point
its all LUCK period
how can you base an efficiency on luck
such an efficiency means NOTHING
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.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
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%.
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
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
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
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
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)
I've only got shares on 4 of 7 blocks
but have a 0 for emp (blocks with out share)
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
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
Any one notice
no payout since the last totally 120 confirms
no payout since the last totally 120 confirms
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
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
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.
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
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
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)
I've only got shares on 4 of 7 blocks
but have a 0 for emp (blocks with out share)
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
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
Jump to: