Topic: ==== Eligius, please pay my 200+ BTC ==== - page 2. (Read 12592 times)

Sure he does. He could even 51% attack p2pool to get up to ~200% PPS (at the expense of everyone else).

But in p2pool the attacker automatically does not get any payout.
Right?

You mean block withholding.
Yes, it does.
It's actually worse there because nobody can stop it.

Does block withdraw method work against p2pool?

I think it is an attack on the economics of decentralization.  Are there more than one way this is true?
Decreasing the "luck" of the pool to get more to join a "luckier" pool increases centralization (and also the effectiveness of this attack).

It is a kin to dumping a product to market under cost to get market share.
The WBA gets nothing for a lost resource to increase the market share of the luckier competitors.

if only there is a way to send a known winning nonce to each suspicious miner to verify they are WBA, you would have incontrovertible proof in the monotoring.

The problem with an accounting method like that is that it can be subverted by a variation of what is called the Sybil attack. You just create new accounts every time you contributed xxxxxxx-1 shares. Because variation has to be reduced significantly to reduce the false positive rate for the "watchdog", xxxxxxx needs to be sufficiently large. An intelligent hacker will use a RNG to make it impossible to distinguish himself from small scale miners. The block withholding attack is not something which can be realistically defeated by statistical analysis.

The long term trajectory is that pools will eventually have to go the KYC route to limit their exposure to WBAs. The WBA is really an attack on the economics of decentralization, but not in the way you think it is.

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

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.

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

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

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

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

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.

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.

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.

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.

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

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.

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.

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.