==== Eligius, please pay my 200+ BTC ====

[bgibso01]

Well I supposed pools could vet miners really carefully like coin base does.

But I don't think miners want to send in id proof of location yada yada yada.

 While the solo fork option stops the attack many miners want the steady .12btc a day that  3x 1th machines bring in on a pool.

 they don't want to go 6-7 months at a time to hit a block.

I am not liking that so far the only thing to stop a bad luck attack is a solo fork option.

I suppose I could get 5 friends with a total of  3th each   we could all solo mine on a fork provided by btcguild or bit minter  or eligus    it should take the 15th about 6 weeks to hit

a block, but with bad luck that 15th could go 18 weeks easy.

This is why if you offer the solo fork as a pool op you take the risk off the pool and put it on the miner.

I am too small of a miner to really worry. 2th  for btc and 25mh for ltc.   if the pools offer a fork I put 10% in the fork and still mine merged with 90%.  And I hope for the best.

This needs to be solved by some clever pool op or mining will suffer a lot.

So I get you wanting a solo fork for pooled mining.  I just can't see the benefit.  Is it so the small miners don't need to keep the block chain on their system?  I also understand your gambler's analogy.  The craps table is my weakness   I've set up eloipool on one of my computers to run and mine some to it for that long-shot payoff.  Can you elaborate more as to why solo pools vs. private pool/bitcoind?

Also, having now caught up on the 6 or 7 pages of reading, is the 'simpleton version' of this that the person was submitting shares that were not real and therefore everyone was getting proportionally lower payouts?  And if that's the case, isn't that a flaw in our pool software design? If he was withholding block solved notification, would that matter? Isn't there the risk someone else would solve the block while he waited?  For myself that does not seem to have an in depth understanding of all this, there appears to be a lot of finger pointing (and probably rightfully so), but another piece of the puzzle is missing for it to click in place.

[jonnybravo0311]

Well I supposed pools could vet miners really carefully like coin base does.

But I don't think miners want to send in id proof of location yada yada yada.

 While the solo fork option stops the attack many miners want the steady .12btc a day that  3x 1th machines bring in on a pool.

 they don't want to go 6-7 months at a time to hit a block.

I am not liking that so far the only thing to stop a bad luck attack is a solo fork option.

I suppose I could get 5 friends with a total of  3th each   we could all solo mine on a fork provided by btcguild or bit minter  or eligus    it should take the 15th about 6 weeks to hit

a block, but with bad luck that 15th could go 18 weeks easy.

This is why if you offer the solo fork as a pool op you take the risk off the pool and put it on the miner.

I am too small of a miner to really worry. 2th  for btc and 25mh for ltc.   if the pools offer a fork I put 10% in the fork and still mine merged with 90%.  And I hope for the best.

This needs to be solved by some clever pool op or mining will suffer a lot.

So I get you wanting a solo fork for pooled mining.  I just can't see the benefit.  Is it so the small miners don't need to keep the block chain on their system?  I also understand your gambler's analogy.  The craps table is my weakness   I've set up eloipool on one of my computers to run and mine some to it for that long-shot payoff.  Can you elaborate more as to why solo pools vs. private pool/bitcoind?

Also, having now caught up on the 6 or 7 pages of reading, is the 'simpleton version' of this that the person was submitting shares that were not real and therefore everyone was getting proportionally lower payouts?  And if that's the case, isn't that a flaw in our pool software design? If he was withholding block solved notification, would that matter? Isn't there the risk someone else would solve the block while he waited?  For myself that does not seem to have an in depth understanding of all this, there appears to be a lot of finger pointing (and probably rightfully so), but another piece of the puzzle is missing for it to click in place.

Simple explanation: miner was submitting real shares; however, shares that would have potentially solved the block were withheld, either due to an innocent coding error in the custom version of cgminer, or a malicious one.  In any case, the result is that by withholding block solutions, the miner gets rewarded for the shares they submit, but everyone gets penalized because block solutions are not also submitted.  Personally, I don't understand the motivation for such an attack since it affects everyone, including the miner.  What benefits does it offer other than to affect the pool's luck statistics?

[S4VV4S]

Well I supposed pools could vet miners really carefully like coin base does.

But I don't think miners want to send in id proof of location yada yada yada.

 While the solo fork option stops the attack many miners want the steady .12btc a day that  3x 1th machines bring in on a pool.

 they don't want to go 6-7 months at a time to hit a block.

I am not liking that so far the only thing to stop a bad luck attack is a solo fork option.

I suppose I could get 5 friends with a total of  3th each   we could all solo mine on a fork provided by btcguild or bit minter  or eligus    it should take the 15th about 6 weeks to hit

a block, but with bad luck that 15th could go 18 weeks easy.

This is why if you offer the solo fork as a pool op you take the risk off the pool and put it on the miner.

I am too small of a miner to really worry. 2th  for btc and 25mh for ltc.   if the pools offer a fork I put 10% in the fork and still mine merged with 90%.  And I hope for the best.

This needs to be solved by some clever pool op or mining will suffer a lot.

So I get you wanting a solo fork for pooled mining.  I just can't see the benefit.  Is it so the small miners don't need to keep the block chain on their system?  I also understand your gambler's analogy.  The craps table is my weakness   I've set up eloipool on one of my computers to run and mine some to it for that long-shot payoff.  Can you elaborate more as to why solo pools vs. private pool/bitcoind?

Also, having now caught up on the 6 or 7 pages of reading, is the 'simpleton version' of this that the person was submitting shares that were not real and therefore everyone was getting proportionally lower payouts?  And if that's the case, isn't that a flaw in our pool software design? If he was withholding block solved notification, would that matter? Isn't there the risk someone else would solve the block while he waited?  For myself that does not seem to have an in depth understanding of all this, there appears to be a lot of finger pointing (and probably rightfully so), but another piece of the puzzle is missing for it to click in place.

Simple explanation: miner was submitting real shares; however, shares that would have potentially solved the block were withheld, either due to an innocent coding error in the custom version of cgminer, or a malicious one.  In any case, the result is that by withholding block solutions, the miner gets rewarded for the shares they submit, but everyone gets penalized because block solutions are not also submitted.  Personally, I don't understand the motivation for such an attack since it affects everyone, including the miner.  What benefits does it offer other than to affect the pool's luck statistics?

Crashing a pool so yours gets better hash rates maybe?

[bgibso01]

I guess that's where I misunderstood the use of a pool.  I didn't realize the miner knows when it solved a block.  I thought the pool distributed the work and determined if a block was solved.  The use of shares was just there as a measurement of how many times a miner submits solutions based on certain difficulties.  If a share was submitted that solved a block, the pool would then make the announcement.  Guess I've just been in lala land about this.

[jonnybravo0311]

Crashing a pool so yours gets better hash rates maybe?

That's just it, though.  You're not crashing the pool, you're only affecting the pool's luck stats and impacting everyone's payouts including your own.  I don't understand why.  Let's say that you are successful in your attack, then what?  Are you hoping that miners get disgruntled and leave that pool?  OK, so now you have to hope that the miners that left all join your own pool?  Seems like a long shot, and a pretty lousy choice of methods to get miners onto your pool, especially since by its very definition you're losing revenue you would have made just mining properly.

Let's say that I have 1PH/s of mining equipment and that I have hacked my miner software to not submit block solutions.  I would have to launch my own pool, and then spend all of my mining efforts trying to disrupt the other pools, all while advertising and trying to draw miners into my pool.  I'm losing revenue the entire time because I'm withholding block solutions.  I'm playing the odds that by causing enough disruption in the other pools, a ton of miners will leave those pools and join mine, at which point I'd fix my software and hash away properly.  Are those odds really that good?  I wouldn't think so.  I would think the revenue lost during my "exploratory" mission would outweigh the gains I *might* make later on.

[Jason]

Crashing a pool so yours gets better hash rates maybe?

That's just it, though.  You're not crashing the pool, you're only affecting the pool's luck stats and impacting everyone's payouts including your own.  I don't understand why.  Let's say that you are successful in your attack, then what?  Are you hoping that miners get disgruntled and leave that pool?  OK, so now you have to hope that the miners that left all join your own pool?  Seems like a long shot, and a pretty lousy choice of methods to get miners onto your pool, especially since by its very definition you're losing revenue you would have made just mining properly.

Let's say that I have 1PH/s of mining equipment and that I have hacked my miner software to not submit block solutions.  I would have to launch my own pool, and then spend all of my mining efforts trying to disrupt the other pools, all while advertising and trying to draw miners into my pool.  I'm losing revenue the entire time because I'm withholding block solutions.  I'm playing the odds that by causing enough disruption in the other pools, a ton of miners will leave those pools and join mine, at which point I'd fix my software and hash away properly.  Are those odds really that good?  I wouldn't think so.  I would think the revenue lost during my "exploratory" mission would outweigh the gains I *might* make later on.

There are some legitimate and worthwhile reasons for performing a block withholding attack.  Let's say that you have a substantial percentage of your net worth in bitcoins and a pool operator is approaching 50% of the net mining rate, threatening the value of your bitcoins.  Might it not make sense for you (and others in a similar situation) to mine at the offending pool operator's site with your miners configured to do a block withholding attack?  Until the pool's luck is adversely affected, you would still receive nearly the same payout you would otherwise receive, but at the same time you would be negatively impacting the luck of the offending pool which would lead other miner's to switch to a different pool once they noticed their earnings began to decline.

[jonnybravo0311]

Crashing a pool so yours gets better hash rates maybe?

That's just it, though.  You're not crashing the pool, you're only affecting the pool's luck stats and impacting everyone's payouts including your own.  I don't understand why.  Let's say that you are successful in your attack, then what?  Are you hoping that miners get disgruntled and leave that pool?  OK, so now you have to hope that the miners that left all join your own pool?  Seems like a long shot, and a pretty lousy choice of methods to get miners onto your pool, especially since by its very definition you're losing revenue you would have made just mining properly.

Let's say that I have 1PH/s of mining equipment and that I have hacked my miner software to not submit block solutions.  I would have to launch my own pool, and then spend all of my mining efforts trying to disrupt the other pools, all while advertising and trying to draw miners into my pool.  I'm losing revenue the entire time because I'm withholding block solutions.  I'm playing the odds that by causing enough disruption in the other pools, a ton of miners will leave those pools and join mine, at which point I'd fix my software and hash away properly.  Are those odds really that good?  I wouldn't think so.  I would think the revenue lost during my "exploratory" mission would outweigh the gains I *might* make later on.

There are some legitimate and worthwhile reasons for performing a block withholding attack.  Let's say that you have a substantial percentage of your net worth in bitcoins and a pool operator is approaching 50% of the net mining rate, threatening the value of your bitcoins.  Might it not make sense for you (and others in a similar situation) to mine at the offending pool operator's site with your miners configured to do a block withholding attack?  Until the pool's luck is adversely affected, you would still receive nearly the same payout you would otherwise receive, but at the same time you would be negatively impacting the luck of the offending pool which would lead other miner's to switch to a different pool once they noticed their earnings began to decline.

You would need to have a relatively significant hash rate compared to the pool overall to impact the luck on the pool.  Also, as you stated, it would take a while for that impact to be noticed.  It just seems to me that taking such action would prove to be more detrimental to you than it would to the pool.  As a mechanism to prevent a pool from gaining 51%?  I absolutely cannot see adding a significant amount of hashing power to a pool that is already flirting with the 51% mark.  Again, unless you have a significant portion of the hash rate of that pool, your attack would not be viable.  And if you did have a significant portion of the hash rate already on that pool, you could simply move your miners somewhere else.

[Jason]

You would need to have a relatively significant hash rate compared to the pool overall to impact the luck on the pool.  Also, as you stated, it would take a while for that impact to be noticed.  It just seems to me that taking such action would prove to be more detrimental to you than it would to the pool.  As a mechanism to prevent a pool from gaining 51%?  I absolutely cannot see adding a significant amount of hashing power to a pool that is already flirting with the 51% mark.  Again, unless you have a significant portion of the hash rate of that pool, your attack would not be viable.  And if you did have a significant portion of the hash rate already on that pool, you could simply move your miners somewhere else.

Assuming that the ~15% drop in recent bitcoin valuation was due to GHash exceeding 50% of the total hash rate (and who knows how much further it may have dropped if that abuse were not terminated), then you would need to lose 15% of your payouts in order for it to hurt you more than performing the attack.  A drop in mining revenue well below that number would already cause a huge number of miners to switch pools, which would accomplish the objective of reducing the hash rate at the offending pool.

I did not mean to suggest that the individual miner could pull of a successful attack single-handed (with a couple of notable exceptions).  But rather that community action of this nature would have a large enough effect in aggregate to get the job done.  If the community reaction to this abuse by GHash is anything to go by, it seems plausible that a large number of miners might participate in such an attack if it were easy to do.

[jonnybravo0311]

You would need to have a relatively significant hash rate compared to the pool overall to impact the luck on the pool.  Also, as you stated, it would take a while for that impact to be noticed.  It just seems to me that taking such action would prove to be more detrimental to you than it would to the pool.  As a mechanism to prevent a pool from gaining 51%?  I absolutely cannot see adding a significant amount of hashing power to a pool that is already flirting with the 51% mark.  Again, unless you have a significant portion of the hash rate of that pool, your attack would not be viable.  And if you did have a significant portion of the hash rate already on that pool, you could simply move your miners somewhere else.

Assuming that the ~15% drop in recent bitcoin valuation was due to GHash exceeding 50% of the total hash rate (and who knows how much further it may have dropped if that abuse were not terminated), then you would need to lose 15% of your payouts in order for it to hurt you more than performing the attack.  A drop in mining revenue well below that number would already cause a huge number of miners to switch pools, which would accomplish the objective of reducing the hash rate at the offending pool.

I did not mean to suggest that the individual miner could pull of a successful attack single-handed (with a couple of notable exceptions).  But rather that community action of this nature would have a large enough effect in aggregate to get the job done.  If the community reaction to this abuse by GHash is anything to go by, it seems plausible that a large number of miners might participate in such an attack if it were easy to do.

Well, it's speculation that GHash was the cause of the price drop in BTC, albeit a very plausible explanation.  Still, why the attack?  Either your miners are already on the pool in question, in which case you'd simply pull them off the pool, or you'd have to add a bunch of hashing power to the pool that is already at or above the 51% hoping that you make a significant enough impact that a large portion of the miners on the pool beyond your own see the reduction in payout and leave.

[KNK]

Why join the pool to attack it, while it is better to leave the pool and join another one to balance the power.
I don't think

Crashing a pool so yours gets better hash rates maybe?

is the reason for performing such attack, because it will never outweight the gain from your's and the attacker may not even have pool, but ...
If you have enough power and you solomine - the next difficulty jump will compensate the power you have added and your return will drop, but if you join a pool and never submit solutions - you keep the difficulty lower than it should be, while still being paid. For a longer (enough) period you will get more even if you are mining at a loss, because you are not adding to the pool your solutions.

Lets say you have 1% of the network and join a pool which is 10% of the network.
Together you have 11%, but get only 10% of the blocks - 14-15 per day instead of 15-16 = you loose 1 block per day, but your share in the pool is 10%, so you only loose 2.5 BTC per day (36.25 instead of 38.75 BTC), but after the next difficulty change (lets assume no other power is added):
 If you submit solutions now the pool has 9.9% and gets 356.4 BTC per day from which you only get 10% or 35.64
 If you do not submit your solutions - you still get 36.25, so start getting 0.61 BTC for each difficulty change and after 4 you start getting more and more than you could have otherwise.

[NewLiberty]

Why join the pool to attack it, while it is better to leave the pool and join another one to balance the power.
I don't think

Crashing a pool so yours gets better hash rates maybe?

is the reason for performing such attack, because it will never outweight the gain from your's and the attacker may not even have pool, but ...
If you have enough power and you solomine - the next difficulty jump will compensate the power you have added and your return will drop, but if you join a pool and never submit solutions - you keep the difficulty lower than it should be, while still being paid. For a longer (enough) period you will get more even if you are mining at a loss, because you are not adding to the pool your solutions.

Lets say you have 1% of the network and join a pool which is 10% of the network.
Together you have 11%, but get only 10% of the blocks - 14-15 per day instead of 15-16 = you loose 1 block per day, but your share in the pool is 10%, so you only loose 2.5 BTC per day (36.25 instead of 38.75 BTC), but after the next difficulty change (lets assume no other power is added):
 If you submit solutions now the pool has 9.9% and gets 356.4 BTC per day from which you only get 10% or 35.64
 If you do not submit your solutions - you still get 36.25, so start getting 0.61 BTC for each difficulty change and after 4 you start getting more and more than you could have otherwise.

If we must consider reasons, and desire to include economics and math, the more important calculation might be the p-value of spend on anger-management therapy.

[jtoomim]

The mathematical probability of you not finding a block with the amount of work required to find 24 blocks is:

One in 81,000,000

ie. pretty fucking unlikely.

http://en.wikipedia.org/wiki/Bonferroni_correction

Eligius has several thousand active users. Let's say 1k users of medium to large size. The probability of one of those users having such extremely bad luck would then be 1000 times higher than 1/81,000,000, or 1/81,000. Still unlikely.

Excuse me if I'm being pedantic, I don't like seeing statistics misapplied in important situations. Yes, I'm often an unhappy person.

[organofcorti]

The mathematical probability of you not finding a block with the amount of work required to find 24 blocks is:

One in 81,000,000

ie. pretty fucking unlikely.

http://en.wikipedia.org/wiki/Bonferroni_correction

Eligius has several thousand active users. Let's say 1k users of medium to large size. The probability of one of those users having such extremely bad luck would then be 1000 times higher than 1/81,000,000, or 1/81,000. Still unlikely.

Excuse me if I'm being pedantic, I don't like seeing statistics misapplied in important situations. Yes, I'm often an unhappy person.

I could be wrong, but I think you have to be careful of misapplying that correction here, don't you? There are lots of miners, and their hash-rates vary from 1 Ghps to (at the time) 2 Phps, and you can't apply a luck correction since they won't have attempted to solve the same amount of blocks in a similar period. Apples and oranges. Of course if the hashrate was split into a thousand smaller workers you could be correct, but only for the ~ 1Thps miner group.

tl;dr I don't think you should compare groups where the worst and best luck cases cannot be the same (because the amount of submitted work is different). If I'm wrong here, please let me know.


In the time period in question (unless I've missed part of the conversation), there was only one miner with 2Phs, and therefore no other miners against which a comparison could be made. Therefore, the probability of [ submitted work ]/[ expected work ] <= 24 is just

Pr(X <= x) = 1 - exp(-24)

and the upper tail probability:

Pr(X > x) = exp(-24) = 3.775135e-11, or 1 in 26 489 122 130.

Edit: While we're on the subject, the "luck" rv, E[[ submitted work ]/[ expected work ]] for n solved blocks is Erlang distributed, where the shape parameter = rate parameter = n.

[Raize]

Btw: Funny how the discussion rolls on, while the guy who opened this thread seems to have disappeared....

He vanished right around the time everyone realized that not only were we owed the 200+ BTC that were held back, but also the 400+ BTC or more that he was paid for mining when he was not contributing.

He probably disappeared because he realized he ain't getting nothing.

He vanished because he wouldn't or couldn't prove he owned either address so there was nothing more to discuss. The consequences of having signed either address would be an admission of fraud on his part, which is a crime by every nation's government on this planet, Bitcoin-related or not.

[Hektur]

In either this thread or the Eligius one, Wizkid did acknowledge that he was provided a valid signed message with those addresses listed.

[thejewelrytech]

Whiz was provided a signature by someone but it wasn't BRUCIE  he did not own the addresses! He was just a paid shill sent to broker the scam and convince people of no wrong doing....... He stated himself TREAT ME AS  A VOLUNTEER to speak for the real owners to speak on their behalf ?
https://bitcointalk.org/index.php?topic=441465.2480 
  Bottom line he was just someone most likely a PAID PR  paid to speak on  behalf of the supposed miner group he was a SHILL.As he can say he never did anything wrong ?and would be telling the truth while being able too cover THE LIE !As He never owned the addresses to begin with....... so everything he had to say was irrelevant he didn't own the addresses so he really had no right to say anything about the situation all his credibility was out the window at that point! Even if he was giving power to speak? Why couldn't the real owners speak for themselves? because they would be clearly lying and would get caught up in their own lies like LIARS ALWAYS DO....So better to find someone else to speak for you so they aren't lying and maybe believe what they were told so in theory they won't be lying? get someone else and CLAIM THEY ARE IT someone who believes THE LIE because only then they can present it as TRUTH since they believe  the lie to begin with! He only claimed he was giving Power to Speak with absolute no Proof of it also?But seemed to know enough to convince people of the situation...... All he knew is what he was told at best too say so I would take anything he ever said with a grain of Salt
No TICKY...... NO LAUNDRY..............

[kano]

I offered this:
When a block is found, send the winning nonce to other large miners and see if one doesn't return it.

* Apparently this can be difficult to do with Stratum.
* If you wait before broadcasting the winning block, another pool may publish first.
* If you publish the block and verify the suspected miner at the same time, the suspected miner may well see the published block and be able to falsely pass your test.


grnbrg.

The merkleroot hashed in a block header, is the root of a tree of transaction hashes.
One of those transaction hashes, is always the coinbase transaction's hash.
Any changes to the coinbase transaction will change the value of the merkleroot.

Thus ... this is used in stratum, where the coinbase transaction is modified to generate work items from a single work sent by the pool.
Thus, it is quite possible that a miner, given exactly the same work from the pool, will not find the same block since:
1) it may not generate the same work items
2) it may not generate and hash as many work items to catch up to finding the block ... especially if it is slower than the block finder.
3) getting a miner to do more than a small amount of extra work (e.g. only 5.5 seconds longer than necessary on the old block to test them) will mean that miner will find more than 1% less blocks.

Just to expand on that: a stratum 32bit nonce2 work from a pool allows for enough work for over 300,000TH/s for 30s - or 4billion possible work items.
Both miners would have to mine the same work item in those 4billion possible work items.
This is possible of course, but not guaranteed.
You could possibly force it, but that's not the only issue ...

Next problem is the fact that not all mining devices mine the same nonce range.
A full nonce range is from 0x0 to 0xffffffff per work item.
Some devices don't do the full range.
Some fail to do parts of the range due to hardware flaws.
Some fail to do parts of the range due to (bad) firmware design.
This of course doesn't make any difference to the chances of finding a block, but it does affect which devices would find the same block.

..........

And then while thinking about this ... I reread my point 3) above ... that would reduce the pool block find rate, by making big hashers find less blocks ...
You'd wanna hope no pool is doing that and causing their own bad luck ...

[NewLiberty]

And then while thinking about this ... I reread my point 3) above ... that would reduce the pool block find rate, by making big hashers find less blocks ...
You'd wanna hope no pool is doing that and causing their own bad luck ...

Thank you for your careful thinking on it.  We started with Linux at the same year.

The check need not be on every found block.
Spot checking could be sufficient.
Also could skip check unless luck is down.
If nonce is in a known range unsupported by some hardware, it may be a false positive detection, which would require a second check for that condition.

Weigh it against the risk that there is malevolent action decreasing your luck.
Maybe it is hard, so was the byzantine general.
Maybe not worth discovering, or maybe Bitcoin is worth it or will be some day.
Maybe there are unintended consequences that must also be handled.
Experimentation will also be needed.  Making the detection nonce block indistinguishable from other work is also a challenge, or counterdetection measures may develop.

Maybe more thought toward this goal of monitoring for bad actors which is not adequate today, will be even more fruitful.  Thank you for your contribution today and for not ignoring what may be an important problem to solve...

[S4VV4S]

Guys, I will ask again since I didn't get an answer before:

Can't you guys build a "watchdog" like program that will check for this things every 30-60 mins let's say.

You can have it connect to your db, load records,

then

if((sharesSubmitted > xxxxxxx) && (blocksFound < x)){

// notify pool ops to monitor that account

}


just a thought, I don't know if this will work or not but I don't see the reason why not, to at least notify you in such case.

[NewLiberty]

Guys, I will ask again since I didn't get an answer before:

Can't you guys build a "watchdog" like program that will check for this things every 30-60 mins let's say.

You can have it connect to your db, load records,

then

if((sharesSubmitted > xxxxxxx) && (blocksFound < x)){

// notify pool ops to monitor that account

}


just a thought, I don't know if this will work or not but I don't see the reason why not, to at least notify you in such case.

This is another good way to reduce the number of more intrusive checks.
Only checking those significantly below the difficultly average.