Bitcoin Forum
December 10, 2016, 01:33:03 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Long Poll and Pool Hopping  (Read 2100 times)
dyngnosis
Jr. Member
*
Offline Offline

Activity: 30


View Profile
August 02, 2011, 04:18:42 PM
 #1

I became interested in bitcoin mining, mining pools and the bitcoin network last week so please excuse the fresh smell.

After reading the initial Satoshi paper and seeing how the implementation has evolved and differed from the original (and brilliant) design I started to consider the 'dangers' of large bitcoin mining pools.  It seems that if a determined attacker was able to compromise just two machines they could compromise the entire bitcoin network[2].. scary stuff for anyone with an investment in bitcoin no?  Defeats the purpose of a non centralized trust model too doesn't it? Anyway...

I decided to fire up wireshark on a couple of my mining rigs and set up filters to grab interesting bitcoin related traffic.  Using pylibpcap and massaging the data shows interesting statistical information (long poll data), server response time changes(as workers all find out that they need need data), and changes in the data value in the RPC request seem to correlate nicely and filtering out the noise gets easier with a larger number of miners.

Question:
Are there any open source pool hoppers out there that are actually using longpoll to assist in block completion estimation or are they all just scraping APIs and web pages for block completion times?

[1] http://www.bitcoin.org/bitcoin.pdf
[2] *...by gaining the majority of the bitcoin C/GPU vote The pool administrators are active and easily contacted.  An attacker with an adobe/java/office 0day could potentially social engineer their way into compromising pool operator personal machines and hop the fence from there.  Operators could be coerced. Operators could be malicious.

1481333583
Hero Member
*
Offline Offline

Posts: 1481333583

View Profile Personal Message (Offline)

Ignore
1481333583
Reply with quote  #2

1481333583
Report to moderator
1481333583
Hero Member
*
Offline Offline

Posts: 1481333583

View Profile Personal Message (Offline)

Ignore
1481333583
Reply with quote  #2

1481333583
Report to moderator
1481333583
Hero Member
*
Offline Offline

Posts: 1481333583

View Profile Personal Message (Offline)

Ignore
1481333583
Reply with quote  #2

1481333583
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481333583
Hero Member
*
Offline Offline

Posts: 1481333583

View Profile Personal Message (Offline)

Ignore
1481333583
Reply with quote  #2

1481333583
Report to moderator
1481333583
Hero Member
*
Offline Offline

Posts: 1481333583

View Profile Personal Message (Offline)

Ignore
1481333583
Reply with quote  #2

1481333583
Report to moderator
hawks5999
Full Member
***
Offline Offline

Activity: 168



View Profile WWW
August 02, 2011, 06:00:43 PM
 #2

Some appear to be attempting to use LP though I'm not sure if it's open source. Primarily that is relying on pident.

Others are definitely open source, but from root to fork generally rely on json stats or regex scraping. Most the work is focused now on different algorithms, but there is always a search for getting more reliable information more quickly.

■ ▄▄▄
■ ███
■ ■  ■               
LEDGER  WALLET    ████
■■■ ORDER NOW! ■■■
              LEDGER WALLET
Smartcard security for your BTCitcoins
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Decentralized. Open. Secure.
gat3way
Sr. Member
****
Offline Offline

Activity: 256


View Profile
August 02, 2011, 07:28:13 PM
 #3

From a miner perspective that was one of the things I targeted for hashkill, but unfortunately it would likely never be released because I have other things to do and bitcoin plugin development is currently frozen. I planned to have two multi-pool modes, failover and load-balance. Failover is easy, but it was exactly long polling that makes load-balance mode difficult to get done properly. My task was also even harder because I spawn a number of workthreads per GPU and utilize all the GPUs within one process. I experimented a bit and found out it is actually hard to get that done properly. Actually I still can't find the best strategy for doing that.
fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW
August 03, 2011, 04:45:54 AM
 #4

Quote
Are there any open source pool hoppers out there that are actually using longpoll to assist in block completion estimation or are they all just scraping APIs and web pages for block completion times?
Not that I know of. There are two issues with trying to identify block finders outside of explicit pool APIs: 1) Block finder estimation has to be accurate. Mining against a proportional pool with >43% shares makes your efficiency <100% (i.e. you're better off mining PPS). So if you guessed wrong, you're now "losing" money. 2) Block finder estimation has to be fast. The most valuable time to mine is at the very beginning of the round. The biggest pools are the primary targets for block finder estimation, and so the problem is much worse. For example, Deepbit's fast rounds (most valuable rounds) are under 10 minutes long. If block finder estimation takes, say, a minute to identify a block's owner then you've lost out on a very large chunk of the round.

The latter problem I assume isn't that bad. Better to have jumped and gotten at least some nice, filthy profit than to not have jumped at all. The former problem is probably the worst. I'm sure someone more involved in the math of pool hopping than I could calculate the required accuracy to make block finder estimation profitable.

The nice thing about having a massive pool like deepbit around is that even a naive block finder estimation (if it isn't any of the known pools, it's probably deepbit) will be correct about 60 to 70% of the time Tongue

iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
August 03, 2011, 05:47:16 AM
 #5

Quote
Are there any open source pool hoppers out there that are actually using longpoll to assist in block completion estimation or are they all just scraping APIs and web pages for block completion times?
Not that I know of. There are two issues with trying to identify block finders outside of explicit pool APIs: 1) Block finder estimation has to be accurate. Mining against a proportional pool with >43% shares makes your efficiency <100% (i.e. you're better off mining PPS). So if you guessed wrong, you're now "losing" money. 2) Block finder estimation has to be fast. The most valuable time to mine is at the very beginning of the round. The biggest pools are the primary targets for block finder estimation, and so the problem is much worse. For example, Deepbit's fast rounds (most valuable rounds) are under 10 minutes long. If block finder estimation takes, say, a minute to identify a block's owner then you've lost out on a very large chunk of the round.

The latter problem I assume isn't that bad. Better to have jumped and gotten at least some nice, filthy profit than to not have jumped at all. The former problem is probably the worst. I'm sure someone more involved in the math of pool hopping than I could calculate the required accuracy to make block finder estimation profitable.

The nice thing about having a massive pool like deepbit around is that even a naive block finder estimation (if it isn't any of the known pools, it's probably deepbit) will be correct about 60 to 70% of the time Tongue

why not verify it against the APIs?

step 1. find all the pools that have correct up to date APIs, including PPS, SMPPS, PPLNS, etc.
step 2. if none of them claim to have found a block, your accuracy goes way up

fpgaminer
Hero Member
*****
Offline Offline

Activity: 546



View Profile WWW
August 03, 2011, 07:56:34 AM
 #6

Quote
why not verify it against the APIs?

step 1. find all the pools that have correct up to date APIs, including PPS, SMPPS, PPLNS, etc.
step 2. if none of them claim to have found a block, your accuracy goes way up
Yup, that gives fairly high accuracy. If you look at pool size estimation at http://pident.artefact2.com/ you can add up all the pools that don't delay or hide their stats, and figure out how accurate a Process of Elimination algorithm would be.

I think if you add up all the stat-friendly pools (ones that don't delay stats) you've covered about 40% of the landscape. I am terrible at statistics, so feel free to correct the following:

1) 40% of the time: A block will be claimed by a stat-friendly pool. You are thus 100% accurate in this case.
2) 60% of the time: A block isn't immediately claimed. It has a 38 in 60 percent chance of being from Deepbit; that's 63%. If you always guessed Deepbit in this case, you'd thus be right 63% of the time.

(40% * 100%) + (60% * 63%) = 77.8%

By either finding the claiming pool, or guessing Deepbit, you are 77.8% accurate.

Not sure if 77.8% is good enough to profit from hopping to Deepbit. It also means you can never hop to BTCguild or any other stat-unfriendly prop pool.

iopq
Hero Member
*****
Offline Offline

Activity: 644


View Profile
August 03, 2011, 10:25:17 AM
 #7

Quote
why not verify it against the APIs?

step 1. find all the pools that have correct up to date APIs, including PPS, SMPPS, PPLNS, etc.
step 2. if none of them claim to have found a block, your accuracy goes way up
Yup, that gives fairly high accuracy. If you look at pool size estimation at http://pident.artefact2.com/ you can add up all the pools that don't delay or hide their stats, and figure out how accurate a Process of Elimination algorithm would be.

I think if you add up all the stat-friendly pools (ones that don't delay stats) you've covered about 40% of the landscape. I am terrible at statistics, so feel free to correct the following:

1) 40% of the time: A block will be claimed by a stat-friendly pool. You are thus 100% accurate in this case.
2) 60% of the time: A block isn't immediately claimed. It has a 38 in 60 percent chance of being from Deepbit; that's 63%. If you always guessed Deepbit in this case, you'd thus be right 63% of the time.

(40% * 100%) + (60% * 63%) = 77.8%

By either finding the claiming pool, or guessing Deepbit, you are 77.8% accurate.

Not sure if 77.8% is good enough to profit from hopping to Deepbit. It also means you can never hop to BTCguild or any other stat-unfriendly prop pool.
now combine that with timing long-polling, and you might be able to predict that it's deepbit almost 100% of the time
and they can't delay that, that would actually screw legitimate miners

Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
August 03, 2011, 10:51:02 AM
 #8

They can try to detect hoppers and delay only for them - which causes more load on their end, still can screw legitimate miners and would still make it quite efficient (fpgaminer didn't include long polling timing or other timing measures in his approach).

It might even be possible to time long polls of other non-delayed pools for a block from a LP-delayed pool, as the route a block announcement takes through the network is most likely quite static for pools.

I guess 1-2 weeks until deepbit and BTCguild will be hoppable again big time, and there is only 1 simple thing to do for them: Switch to a proper payout system. Everything else either hurts them + their miners too or doesn't help against hopping at all.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
hawks5999
Full Member
***
Offline Offline

Activity: 168



View Profile WWW
August 03, 2011, 03:56:59 PM
 #9

Mining today is a race between pool operators striving to build bigger and better hopping-proof programs, and the Universe trying to produce bigger and better hopppers. So far, the Universe is winning.

Apologies to Rick Cook.

■ ▄▄▄
■ ███
■ ■  ■               
LEDGER  WALLET    ████
■■■ ORDER NOW! ■■■
              LEDGER WALLET
Smartcard security for your BTCitcoins
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Decentralized. Open. Secure.
Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
August 03, 2011, 06:13:32 PM
 #10

Well, a lot of pool operators already switched to hopping proof algorithms. Once all switch, hopping is dead. As long as even one keeps proportional, it will be hoppable + be hopped.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
ed64
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 05, 2011, 02:44:51 AM
 #11

Hoping will probably always be profitable given that every pool has a run of bad luck now and then. I think the margins will shrink though and make it less viable and more of a hobby...

Send your BTC to a loving home: 1CWjg4soWEAQjMD4dCchdPpJ6fWDBRUU5b
Github: https://github.com/echiu64/
Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
August 06, 2011, 08:25:03 PM
 #12

Once you realize a pool has bad luck, it's already too late... Wink

But yes, payouts using any other scheme than pure PPS will show a bit of variance over time.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
lucita777
Jr. Member
*
Offline Offline

Activity: 39


View Profile
August 19, 2011, 11:17:31 PM
 #13

Variance alone does not make a pool hoppable. Only unfair payout system does.

Otherwise, good luck with hopping a roulette in the casino - it also has large variance Smiley
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!