geebus


March 31, 2011, 03:18:26 AM 

The only validity to the pool hopping exploit I can see is if you could put yourself in a position where you started off at Bitcoin Pooled Mining (BPM) and had a decent chunk into it and bailed toward the end for Bitcoin Pool (BP). From what I have read, and I could be wrong or outdated info, shares at BPM are weighted more heavily toward the end so if you had a decent stake in the current block at BPM and managed to switch over to BP at the beginning of a new block to establish a stake there too. Both blocks would have to terminate rather quickly and at about the same time for it to work and not have the shares get ate up at BPM.
It's possible, but highly unlikely considering you would have to get lucky with the timing on both sites.
They're not weighted toward the end, it's that they favor later shares. So, after a period of time, the shares are reduced in value, whether submitted at the start of the round, middle of the round, or end. After time, the shares are worth less than they were at time of submission. Likewise, if switching to bitcoinpool after a lengthly chunk of the round had already occurred, your shares would be worth a minuscule portion of the total payout, unless you had a blazingly fast mining setup. So, essentially, you're gambling twofold. One, that you're going to be able to switch to bitcoinpool from slush's pool and have slush's pool solve the block before your shares devalue, and two, that you're going to be able to generate a large enough share base on bitcoinpool to award a payout, also assuming that they will solve the block in short time. All of this is likewise being assumed off of the hash speed of the pool, which isn't a good figure for assuming the speed at which a pool can solve a block because of fluctuations in the user base. Calculations on average time to solve assume that you're constantly working, at a fixed average hash speed, and mining on complete and consecutive pieces of work until an answer is found. Thats not how pool mining works. You may have 10 users with a combined speed of 1Ghash/s, but there may only be 2 people hashing every nonce in the getwork while the other 8 are working off of only a portion before moving on to the next work. That fact alone will flaw the estimate of block solve time... and unless you're calculating your pool solve time estimates with fuzzy logic to incorporate the human factor, you're always going to be off. It's a gamble, and not a mathematically proven theorem... and without thousands of solved blocks worth of "pool hopping" data, there would be no way to even have remotely enough data to actually prove it, so you're left with speculation. Likewise, pool speeds are based off of a submissionsovertime calculations, not a live and exact representation of pool speed. I could hash at 1 Gh/s, but take 20 getworks before I found an answer. As far as the hash speed of the pool is concerned, I'm mining slowly because I submitted few shares in xamount of time.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ




Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

grndzero


March 31, 2011, 03:28:35 AM 

I agree. Basically there's no way to prove it except for saying you got lucky and pulled it off once or twice.
If someone could do this reliably then they would be predicting when blocks would be found on more than 1 site then they might as well build a massive solo rig and do it for themselves rather than losing money in pools.

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


March 31, 2011, 03:36:27 AM 

You don't understand the exploit.
It has absolutely nothing to do with using the hash rate of the pool to try and guess when a block will be solved. It has absolutely nothing to do with trying to figure when a block will be solved at all. That question is completely indeterminate and thus why trying to guess at such is a fool's game.
The exploit is that in a Share based pool, there are diminishing returns past a certain point in a round. Each share that is submitted makes each other share that has been submitted worth less and less, including the one you just submitted to make all those others (and yours) worth less (per share).
The value of these shares can be plotted on a graph and the plot will be nonlinear.
Every nonlinear graph has an inflection point. In this case, the inflection point represents when the law of diminishing returns makes it no longer worth your effort to continue to contribute to this round in the pool. Once you have hit that point, you can go anywhere else that has not yet reached that inflection point (solo, any score based pool, a PPS pool, or any Share based pool that also hasn't reached the inflection point) and have your effort rewarded at a higher rate than it would be in the original pool (until the original pool finishes a round and is thus no longer past the inflection point).
Since the inflection point has been mathematically determined and published in Raulo's paper, it is extremely easy to implement an attack to exploit this problem.
And again, the "jumping ship" and severe decrease in your pool's hash rate during a long round that you noticed is exactly indicative of (but not proof) of purposeful implementations of this attack being utilized against your pool.
Edit: And people that are implementing this attack against your pool are stealing their extra earnings from the other noncheating miners in your pool.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr



geebus


March 31, 2011, 03:51:04 AM 

I do understand it, it just isn't feasible.
Say we have 99 people, each of whom has submitted 2 shares.
Now lets say person 100 is the "attacker". They join the pool and submit 2 shares. Thus earning them an equal percentage. Then they leave, as they've hit the point in which they now have their equal share, and are simply maintaining a percentage from there on out, as opposed to gaining from nothing.
The round continues on for a few hours. Those 200 shares then turn into 20000 shares over time. Of which, 19998 belong to the first 99 people, and the last 2 belonging to the attacker who jumped ship.
The attacker has reduced their payout from 2% of the total, to 0.02% of the total.
The only way they could effectively attack the pool is to determine the total number of shares that 100% CFD would be, for the pool, and submit 2x that number of shares by themselves, then jump ship to another pool... and even then, that isn't stealing money from others, it's simply guaranteeing that they maintain their original percentage of the payout over time.
It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout. If anyone claims to have done this, they got lucky once or twice, and the few times that they are dramatically unlucky will balance that out, thus maintaining the average.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ



yrral


March 31, 2011, 04:05:50 AM 

I do understand it, it just isn't feasible.
Say we have 99 people, each of whom has submitted 2 shares.
Now lets say person 100 is the "attacker". They join the pool and submit 2 shares. Thus earning them an equal percentage. Then they leave, as they've hit the point in which they now have their equal share, and are simply maintaining a percentage from there on out, as opposed to gaining from nothing.
The round continues on for a few hours. Those 200 shares then turn into 20000 shares over time. Of which, 19998 belong to the first 99 people, and the last 2 belonging to the attacker who jumped ship.
The attacker has reduced their payout from 2% of the total, to 0.02% of the total.
The only way they could effectively attack the pool is to determine the total number of shares that 100% CFD would be, for the pool, and submit 2x that number of shares by themselves, then jump ship to another pool... and even then, that isn't stealing money from others, it's simply guaranteeing that they maintain their original percentage of the payout over time.
It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout. If anyone claims to have done this, they got lucky once or twice, and the few times that they are dramatically unlucky will balance that out, thus maintaining the average.
Not true. Let me explain. Lets say I contribute to 5% of the pool (which generates 100 shares an hr), thus I generate 5 shares/hr. I will make 2.5 bitcoins when a round finishes. This is true as long as I keep mining. However, lets say this round is really long, and past some point (say 10 hrs  1000 shares) I jump ship. When I jump ship, I still will make 2.5 bitcoins from my mining time from this pool if it hits immediately. If the pool hits 1 hour after I jump ship (hits the 11th hr), I will make 50*(50/(1000+95))=2.28310502 bitcoins. If another pool (lets say pershare) pays me more than (2.52.2831)/5 bitcoins per work verification, I will be making more bitcoins than just the 2.5 I would have made if I stayed in your pool. Also, for each additional hour after the time I jump ship, the amount extra that I make by jumping ship increases. So I think my way is better. Just keep a sliding window (n hr) of the number of shares submitted by a user. And when we hit, split payout based on faction of work done in the past n hrs. Don't clear the window when we hit. This discourages people hopping and encourages people to stay in the pool. (unless there is a flaw here that I don't see.




xenon481


March 31, 2011, 04:09:10 AM 

I do understand it, it just isn't feasible.
Say we have 99 people, each of whom has submitted 2 shares.
Now lets say person 100 is the "attacker". They join the pool and submit 2 shares. Thus earning them an equal percentage. Then they leave, as they've hit the point in which they now have their equal share, and are simply maintaining a percentage from there on out, as opposed to gaining from nothing.
The round continues on for a few hours. Those 200 shares then turn into 20000 shares over time. Of which, 19998 belong to the first 99 people, and the last 2 belonging to the attacker who jumped ship.
The attacker has reduced their payout from 2% of the total, to 0.02% of the total.
The only way they could effectively attack the pool is to determine the total number of shares that 100% CFD would be, for the pool, and submit 2x that number of shares by themselves, then jump ship to another pool... and even then, that isn't stealing money from others, it's simply guaranteeing that they maintain their original percentage of the payout over time.
It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout. If anyone claims to have done this, they got lucky once or twice, and the few times that they are dramatically unlucky will balance that out, thus maintaining the average.
You are absolutely incorrect. Both in implementation and in the numbers required to make the attack significant. It doesn't take 100% CFD, you jump ship around 40% CFD which is where the inflection point is. It is not possible to reach 100% CFD as the equation is asymptotic against the 100% marker and can never reach it. As 100% CFD is not possible to reach, it is also not possible to submit shares up to 200% CFD. It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout.
This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120130% (on average) of what your true average daily payout should have theoretically been given your hash rate.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr



[Tycho]


March 31, 2011, 04:19:49 AM 

Both in implementation and in the numbers required to make the attack significant. It doesn't take 100% CFD, you jump ship around 40% CFD which is where the inflection point is. It is not possible to reach 100% CFD as the equation is asymptotic against the 100% marker and can never reach it. As 100% CFD is not possible to reach, it is also not possible to submit shares up to 200% CFD.
May be he means current difficulty percentage, not CFD ? Right %% for jumping is somewhere about ~43% It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout.
This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120130% (on average) of what your true average daily payout should have theoretically been given your hash rate. Not sure if in reality it can give you more than +30%. Depends on what statistic is released from pool.

Welcome to my bitcoin mining pool: https://deepbit.net  Both payment schemes (including PPS), instant payout, no invalid blocks ! ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures ( NEW!). Third year in bitcoin business.



xenon481


March 31, 2011, 04:34:46 AM 

It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout.
This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120130% (on average) of what your true average daily payout should have theoretically been given your hash rate. Not sure if in reality it can give you more than +30%. Depends on what statistic is released from pool. You may be right for Pool>Solo jumping, but the expectation would be larger when jumping from one Share Pool to another Share Pool assuming the new Share Pool was currently below the inflection point. The more Share Pools that exist, the easier it would be to guarantee that at least one of them would be below the inflection point. And it wouldn't be hard to write a miner switcher program (some already exist for disconnect prevention) that picks the best (intelligent guess) pool to switch to. Using Block Explorer to see the last time each of the pools found a block (thus when they last started a round) taking the most recently published estimated hashing rates of the pools

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr



geebus


March 31, 2011, 04:40:57 AM 

This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120130% (on average) of what your true average daily payout should have theoretically been given your hash rate.
Prove it. Show it being done. Not theories on paper. Give me a reasonably sized data set proving it, in comparison to daily payouts when not pool hopping, with a comparable set of control data. Likewise, include your daily average from gribble, and gather the sets during a period of identical difficulty. Get the daily earnings both before and after. If you make more money per day, consistently for a period of time as long as the average block solve time that gribble reports, I'll believe you. If you can show it is ACTUALLY feasible, and not a theory on paper, I will believe you. Otherwise, I think it's completely bullshit and I will ask you not to speak of it in this thread again.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ



yrral


March 31, 2011, 04:44:21 AM 

This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120130% (on average) of what your true average daily payout should have theoretically been given your hash rate.
Prove it. Show it being done. Not theories on paper. Give me a reasonably sized data set proving it, in comparison to daily payouts when not pool hopping, with a comparable set of control data. Likewise, include your daily average from gribble, and gather the sets during a period of identical difficulty. Get the daily earnings both before and after. If you make more money per day, consistently for a period of time as long as the average block solve time that gribble reports, I'll believe you. If you can show it is ACTUALLY feasible, and not a theory on paper, I will believe you. Otherwise, I think it's completely bullshit and I will ask you not to speak of it in this thread again. http://bitcointalk.org/index.php?topic=4291.msg76090#msg76090My explanation shows that by pool hopping to a pay per share pool after the inflection point, you will be guaranteed to be making more bitcoins than if you stayed in your original pay per share pool.




[Tycho]


March 31, 2011, 04:48:03 AM 

The more Share Pools that exist, the easier it would be to guarantee that at least one of them would be below the inflection point. This may be true if you can be 100% sure about a) which blocks were minted by each pool, b) what is current share count of each pool (well, this one may allow some margins).

Welcome to my bitcoin mining pool: https://deepbit.net  Both payment schemes (including PPS), instant payout, no invalid blocks ! ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures ( NEW!). Third year in bitcoin business.



xenon481


March 31, 2011, 04:48:37 AM 

This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120130% (on average) of what your true average daily payout should have theoretically been given your hash rate.
Prove it. Show it being done. Not theories on paper. Give me a reasonably sized data set proving it, in comparison to daily payouts when not pool hopping, with a comparable set of control data. Likewise, include your daily average from gribble, and gather the sets during a period of identical difficulty. Get the daily earnings both before and after. If you make more money per day, consistently for a period of time as long as the average block solve time that gribble reports, I'll believe you. If you can show it is ACTUALLY feasible, and not a theory on paper, I will believe you. Otherwise, I think it's completely bullshit and I will ask you not to speak of it in this thread again. It is nice to see that you do not believe that mathematical proofs (not theories, but proofs) don't mean anything. That's like saying that the mathematical proof that shows that "X = 1 + Y" is the equivalent to "X  Y = 1" is absolutely meaningless until you manually substitute and solve both equations for a statistically large set of possible X and Y values. Raulo published a full mathematical proof that the poolhopping attack does in fact increase expected average payouts. Read it.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr



geebus


March 31, 2011, 07:01:15 AM 

It is nice to see that you do not believe that mathematical proofs (not theories, but proofs) don't mean anything.
That's like saying that the mathematical proof that shows that "X = 1 + Y" is the equivalent to "X  Y = 1" is absolutely meaningless until you manually substitute and solve both equations for a statistically large set of possible X and Y values.
Raulo published a full mathematical proof that the poolhopping attack does in fact increase expected average payouts. Read it.
faith [feyth]–nounbelief that is not based on proof proof [proof]nounevidence sufficient to establish a thing as true, or to produce belief in its truth. Theory is not evidence.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ




geebus


March 31, 2011, 07:38:06 AM 

Yeah, server went offline. It will be back up ASAP.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ



FairUser


March 31, 2011, 09:47:18 AM 

Server is back online.




slush


March 31, 2011, 09:55:59 AM 

Prove it.
There's no doubt that the attack will work. So I'm open to test this attack with my 3Ghash against your pool. Does your previous post mean that you agree with this realworld test? I will welcome +2030% of my daily income . I already have tycho's pool block detector, so I can switch between your pools pretty easily. Let's make some fun . If you can show it is ACTUALLY feasible, and not a theory on paper, I will believe you. Otherwise, I think it's completely bullshit and I will ask you not to speak of it in this thread again.
Kids usually don't believe that cooker is really hot. They need to touch it.




grndzero


March 31, 2011, 10:04:07 AM 

poclbm connected. no website from here.

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



CryptikEnigma


March 31, 2011, 10:04:33 AM 

Server is back online.
I know its just me, but it is still down for me, any ideas? Edit: Neither the website or poclbm is working for me still.




FairUser


March 31, 2011, 10:11:05 AM 

Server is back online.
I know its just me, but it is still down for me, any ideas? Edit: Neither the website or poclbm is working for me still. DNS change might take about an hour to propagate. Patience please...




