Bitcoin Forum
December 04, 2016, 10:17:43 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 [109] 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 358672 times)
flower1024
Hero Member
*****
Offline Offline

Activity: 854


luck is just a share away


View Profile
July 14, 2011, 07:53:07 PM
 #2161

but that doesn't help at all as you don't know who found the block.

could be a solo miner.

multipool tried to detect new rounds on deepbit that way. it wasn't very efficient.
1480846663
Hero Member
*
Offline Offline

Posts: 1480846663

View Profile Personal Message (Offline)

Ignore
1480846663
Reply with quote  #2

1480846663
Report to moderator
1480846663
Hero Member
*
Offline Offline

Posts: 1480846663

View Profile Personal Message (Offline)

Ignore
1480846663
Reply with quote  #2

1480846663
Report to moderator
1480846663
Hero Member
*
Offline Offline

Posts: 1480846663

View Profile Personal Message (Offline)

Ignore
1480846663
Reply with quote  #2

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

Posts: 1480846663

View Profile Personal Message (Offline)

Ignore
1480846663
Reply with quote  #2

1480846663
Report to moderator
fcmatt
Legendary
*
Offline Offline

Activity: 1106


View Profile
July 14, 2011, 08:00:25 PM
 #2162

but that doesn't help at all as you don't know who found the block.

could be a solo miner.

multipool tried to detect new rounds on deepbit that way. it wasn't very efficient.

i recall reading about that. people were making an assumption that if a block was found
and using the JSON API did not show it.. they assumed it was deepbit.. but that leaves
out solo miners, private pools, and non-pool friendly pools, etc...

so if a couple more people delay stats.. like btcguild.. it would make guessing which pool
solved that block via LP very confusing. two of the largest pools would be confusing their
software nicely.

i wonder how long of a delay is optimal if btcguild owner decides to implement it?
flower1024
Hero Member
*****
Offline Offline

Activity: 854


luck is just a share away


View Profile
July 14, 2011, 08:06:23 PM
 #2163

i dont like stats delay - but its a very good way to stop hopping.

and: for a pool of the size of btcguild it really doesn't matter. hopper can't jump in rounds less then one minutes. and they are REALLY hot..

so i do believe for btcguild there is nothing to change.

for small pools i prefer a different way: user transparency Smiley

just show an additional (anonymous) stats page where everybody can see how many people profited how much more from a pool-hopping-like behavior (for a pool owner ist easy to detect if a users leaves early regulary).

let their users vote what to do (but be fair; no banning without giving them their funds eg)
TheMalon
Member
**
Offline Offline

Activity: 70


View Profile
July 14, 2011, 08:08:45 PM
 #2164

but that doesn't help at all as you don't know who found the block.

could be a solo miner.

multipool tried to detect new rounds on deepbit that way. it wasn't very efficient.

i recall reading about that. people were making an assumption that if a block was found
and using the JSON API did not show it.. they assumed it was deepbit.. but that leaves
out solo miners, private pools, and non-pool friendly pools, etc...

so if a couple more people delay stats.. like btcguild.. it would make guessing which pool
solved that block via LP very confusing. two of the largest pools would be confusing their
software nicely.

i wonder how long of a delay is optimal if btcguild owner decides to implement it?

It helps a lot ... you don't have to know who solved the block ...
All you need to know is when a pooll starts mining for a new block (this informations is announced using the LP feature) ...


flower1024
Hero Member
*****
Offline Offline

Activity: 854


luck is just a share away


View Profile
July 14, 2011, 08:10:56 PM
 #2165

no

lp announces a new block ANYWHERE on the network

and you just want to enter THAT pool. but how do you find out which one it was?
TheMalon
Member
**
Offline Offline

Activity: 70


View Profile
July 14, 2011, 08:16:01 PM
 #2166

lp announces a new block ANYWHERE on the network

Ohh... that's new ... i've just learned something Smiley
lemonginger
Full Member
***
Offline Offline

Activity: 210


firstbits: 121vnq


View Profile
July 14, 2011, 08:47:57 PM
 #2167

Hoopers, at least inteligent hoopers, only jump to pools that just started a round, and then leave to join another pool that just started their round. Im sure there will be better optimizations, I am not a pool hooper so I dont know them. But the key is that you know when a round starts, but not when a round ends, so by being at the beggining of each round in different pools you increase the probability of getting the more profitable shares while avoiding part of the less profitable shares.

They key is that you know when a round starts but not when it ends.

But I don't understand why this matters. No matter where you are in the round the chance of finding a block is exactly the same. It isn't higher at the beginning. That's like saying you could win at Roulette by just going around and betting on black at any roulette wheel that had come up red the spin before because it makes black more likely. Each hash is a statistically independent event, right?
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 08:53:53 PM
 #2168

But I don't understand why this matters. No matter where you are in the round the chance of finding a block is exactly the same. It isn't higher at the beginning. That's like saying you could win at Roulette by just going around and betting on black at any roulette wheel that had come up red the spin before because it makes black more likely. Each hash is a statistically independent event, right?

Yes, but that does not matter here because the point of a pool is that it does not matter who finds the block in the pool. No matter who is the miner that finds the block the profits are shared. In the pool what matters is how many shares you send and how much you earn for each share.

The key is that by being only at the beggining of the rounds you get a higher chance of getting more shares from short rounds (the more profitable shares) while avoiding a big part of the shares from the long rounds (the less profitable ones).
Thor
Newbie
*
Offline Offline

Activity: 27


View Profile
July 14, 2011, 09:24:01 PM
 #2169

I am really sick of people referring to pool hopping as "cheating" or "hurting the pool" or "stealing other miners' money".  It's not. 

The only purposes I can think of for mining in a pool is to reduce your personal variance, and/or features the pool offers to help monitor your workers (allowing you to reduce your variance further).  The larger the pool is (higher hash rate) the lower your variance should be.

A higher hashrate for any portion of a block reduces your variance further and keeps your expected payout per minute of mining exactly the same.  In trying to refute this, please run some numbers on length of round, hashrate for different portions of it, and number of shares submitted.  If they hop out after some amount of time, that round is still statistically more likely to be over sooner, because more hashes were introduced earlier.  As Eleuthria said a few posts up, this is not to say that people who are skillfully pool hopping aren't making more than they would just sitting in one pool (because they should be, or they're doing it wrong).  It is just to say that in doing so they are helping you to reduce your variance as well.  You can be jealous of their coding skill if you like, but call it that rather than an "attack" or "ripping you off".

Also, hopping with smaller pools is just as effective as hopping with larger ones, it just increases your variance in exactly the same way as mining in said pool full time would.
PcChip
Sr. Member
****
Offline Offline

Activity: 294



View Profile
July 14, 2011, 09:27:07 PM
 #2170

I agree completely with Sharky.  Also, whether or not you or I (or anyone else in this thread) understands why pool hoppers cost the rest of us money doesn't mean they don't cost us money.  How do I know this?  Because a few months ago a user submitted a fully worked out statistical/mathmatical proof that showed how they make an extra percentage by only joining at the beginning of rounds.  If they make more than they deserve, we make less than we deserve.

I'll try to find that proof PDF file...

All rates with Phoenix 1.50 / PhatK
------------------------------------------------------------------------------------------------------------------------------
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
July 14, 2011, 09:29:06 PM
 #2171

I am really sick of people referring to pool hopping as "cheating" or "hurting the pool" or "stealing other miners' money".  It's not. 

The only purposes I can think of for mining in a pool is to reduce your personal variance, and/or features the pool offers to help monitor your workers (allowing you to reduce your variance further).  The larger the pool is (higher hash rate) the lower your variance should be.

A higher hashrate for any portion of a block reduces your variance further and keeps your expected payout per minute of mining exactly the same.  In trying to refute this, please run some numbers on length of round, hashrate for different portions of it, and number of shares submitted.  If they hop out after some amount of time, that round is still statistically more likely to be over sooner, because more hashes were introduced earlier.  As Eleuthria said a few posts up, this is not to say that people who are skillfully pool hopping aren't making more than they would just sitting in one pool (because they should be, or they're doing it wrong).  It is just to say that in doing so they are helping you to reduce your variance as well.  You can be jealous of their coding skill if you like, but call it that rather than an "attack" or "ripping you off".

Also, hopping with smaller pools is just as effective as hopping with larger ones, it just increases your variance in exactly the same way as mining in said pool full time would.

If this is about programming skill, then you wont mind that the pools delay their information one hour. Without the info about when a new round starts in each pool, lets see how those programming skills help you.
Thor
Newbie
*
Offline Offline

Activity: 27


View Profile
July 14, 2011, 09:34:40 PM
 #2172

I refuse to do this:

http://xkcd.com/386/

Believe what you will.
fcmatt
Legendary
*
Offline Offline

Activity: 1106


View Profile
July 14, 2011, 09:45:51 PM
 #2173

I refuse to do this:

http://xkcd.com/386/

Believe what you will.

edited a bit:

well by delaying the stats those who hop around might have to just end up picking a pool and sticking with it if the larger pools do it.
the smaller pools probably want the increased traffic so they can lower the variance and the hoppers can stick with smaller pools.
thus the larger pools enjoy more dedicated resources all the time then just at the beginning of rounds.
and the smaller pools can decrease their variance by being hospitable for pool hopping.
there is no proof that i can see that delaying stats for an hour causes a pool to lose users. just look at deepbit.
also the amount of mh/s hopping, based on what i see, is only 100-200 gh/s (just a guess). if they never come back it is not
like the pool suffers greatly in the way of variance as btcguild is 2 TH/s already without them.

but in the end.. i just have to wonder if it really matters to me. sure i want to make more BTC per share.. but if it is only
.05% less do i really care? and what does it matter to the owner of btcguild.. either way his pool operates as he wants.
sharky112065
Sr. Member
****
Offline Offline

Activity: 383



View Profile
July 14, 2011, 09:51:47 PM
 #2174

I refuse to do this:

http://xkcd.com/386/

Believe what you will.

well by delaying the stats those who hop around might have to just end up picking a pool and sticking with it if the larger pools do it.
the smaller pools probably want the increased traffic so they can lower the variance and the hoppers can stick with smaller pools.
thus the pool enjoys more dedicated resources all the time then just at the beginning of rounds.
there is no proof that i can see that delaying stats for an hour causes a pool to lose users. just look at deepbit.
also the amount of mh/s hopping, based on what i see, is only 100-200 gh/s (just a guess). if they never come back it is not
like the pool suffers greatly in the way of variance as btcguild is 2 TH/s already without them.

AMEN!

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
July 15, 2011, 12:48:12 AM
 #2175

FYI:  US Central's problems are not a software/hardware problem on our end.  According to IRC there's a major DDoS hitting Softlayer right now, and MANY websites are being effectively put offline.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
compro01
Hero Member
*****
Offline Offline

Activity: 485


View Profile
July 15, 2011, 12:50:55 AM
 #2176

speaking of problems, is there any plan on when "miner idle" emails will start operating again?
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
July 15, 2011, 01:19:15 AM
 #2177

FYI, the idles I'm sure almost everybody experienced just now were the result of overall bitcoin network finding 4 blocks in 1 minute and 13 seconds.  That many long polls that frequently can do a number on bitcoind's getwork code, even with all the optimizations we've had added, not to mention the volume of network traffic.


EDIT:  I take it back, apparently Super Server (US West) had no issue on that spam of LPs!

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
psychok9
Full Member
***
Offline Offline

Activity: 224


View Profile
July 15, 2011, 01:49:43 AM
 #2178

Hello!
I have a question: the share/payment system on this pool it's bad for non-24hrs miner (like PPLNS)?
I'm a gamer, and very often (3-5 hours day) I disable or slow down my miner.
Sometime I shutdown the system for the night Smiley
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
July 15, 2011, 01:58:19 AM
 #2179

Hello!
I have a question: the share/payment system on this pool it's bad for non-24hrs miner (like PPLNS)?
I'm a gamer, and very often (3-5 hours day) I disable or slow down my miner.
Sometime I shutdown the system for the night Smiley

Our pool is purely proportional payouts, meaning you'll get paid (Your Shares / Total Shares) * 50 BTC.  The timing of your share submissions, or turning your miner on/off have no negative effects other than the fact that you're not mining.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
sgravina
Sr. Member
****
Offline Offline

Activity: 442



View Profile
July 15, 2011, 03:27:41 AM
 #2180

My seven miners were connected to central.  They all stopped at the same time and I couldn't reconnect.  They are all connected to east now.  It happened at the end of the 3 hour block and I missed three fast blocks before I came home and changed servers.

Why?

Sam
Pages: « 1 ... 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 [109] 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  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!