genjix
Legendary
Offline
Activity: 1232
Merit: 1000


May 09, 2011, 12:40:01 AM 

Observing now the hashrate distribution and knowing someone who sold their BTC because of the current distribution... it would seem in the best interests financially of both Deepbit miners and the Bitcoin economy as a whole if Deepbit were to branch out and 'demonopolize'. I'm not sure exactly how these mining pools work. If Deepbit is using closed software which gives them an edge, I hope that their members have access to the code of that software... otherwise it is very damaging the the confidence of the entire BTC world and this will no doubt negatively effect the bottom line of the Deepbit miners.
Perhaps I'm a nontechnical noob, but please let me know why this disparity exists.







BOUNTY PORTALS BLOG WHERE BOUNTY MANAGEMENT MEETS AUTOMATION SIGNATURE CAMPAIGNS TWITTER FACEBOOK MEDIA CAMPAIGNS AND MORE!



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



genjix
Legendary
Offline
Activity: 1232
Merit: 1000


May 09, 2011, 12:40:36 AM 

BTW, this is not genjix (I didn't realize I was signed into his account)




[Tycho]


May 09, 2011, 12:44:20 AM 


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


May 09, 2011, 12:44:26 AM 

BTW, this is not genjix (I didn't realize I was signed into his account)
So, who is this then, and why would you be logged into his account?

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr



bitlotto


May 09, 2011, 12:50:31 AM 

BTW, this is not genjix (I didn't realize I was signed into his account)
LOL what?

*Next Draw Feb 1* BitLotto: monthly raffle (0.25 BTC per ticket) Completely transparent and impossible to manipulate who wins. TOR TOR2WEB Donations to: 1JQdiQsjhV2uJ4Y8HFtdqteJsZhv835a8J are appreciated.



PwrLeveld
Member
Offline
Activity: 84
Merit: 10


May 09, 2011, 12:53:40 AM 

LOL what? x2




genjix
Legendary
Offline
Activity: 1232
Merit: 1000


May 09, 2011, 01:21:05 AM 

BEGIN PGP SIGNED MESSAGE Hash: SHA1 Friend of mine. I logged onto his PC without telling him because my internet was acting up. BEGIN PGP SIGNATURE Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNx0QcAAoJEH8nvZxjT+xntDUIAJCDWzrK8zVf0D9jhTp4T55y +5IMN4O6tPyJt6DUoKbCGmacRzINservU9HckaN29N2/Dtqw+P5nJIdHWR9so7Rj b0DAMu/gFdkHdbeIbKL1oFHz6OE9Pql7tNjN+jhvAvT8sdywwDFm32360TluXXdj twSO1vKUQVMsLpghsUntnB6Xc1rY5+O3Kb+1TmouvvwfLvhOZQ0F+J1wVadCOOqV Ee/SphySrtDi0zHoYgUo/xYQ13HwWhhb7RCIMU9k6kNoL0pSISnmBGGZvf256E8+ rBiQ4N6BhBTa46MvvWlzekE64scpGgsyIRCpffX3kHskQWGAZWAurI8I2R4p+hA= =uttF END PGP SIGNATURE http://www.bitcoin.org/genjix.gpg




marcus_of_augustus
Legendary
Offline
Activity: 2562
Merit: 1044


May 09, 2011, 02:45:25 AM 

There is an incentive to not mine with deepbit.net (or any other pool) as it gets too big, particularly for the smaller miners.
The pool is there to smooth out the variance. But if the pool is finding blocks too quickly then a smaller, proportional miner may not get that many shares of each short block found and variance starts to return again, and more luck is involved. If you go paypershare this is smoothed out but at the cost of 10% fee with deepbit.net.
The smaller miners are better off with a pool that is finding blocks over a good period of time ... 12 hours, so that their share of the pool is wellrepresented and has had time to average out.
I'm sure if someone is interested, there is some mathematics to be done here that will give you an optimum size of a pool to associate with (as percentage of total network) dependent upon on the miner's hash power (as percentage of the pool), in order to minimise variance .... if that is what you are after.
Robust payments, low fees, info API's, and other bells 'n whistles maybe what you are looking for in a pool also.




anodyne


May 09, 2011, 03:23:14 AM 

Couldn't that "short block variance" be mitigated by calculating rewards/shares for multiple blocks instead of dividing them one by one? With a straight, proportional payout system it would simply mean that shares for blocks that are found in less than XX minutes are transferred to the next block.

Bitcoins: solid enough to build pyramids.



marcus_of_augustus
Legendary
Offline
Activity: 2562
Merit: 1044


May 09, 2011, 04:41:25 AM 

Couldn't that "short block variance" be mitigated by calculating rewards/shares for multiple blocks instead of dividing them one by one? With a straight, proportional payout system it would simply mean that shares for blocks that are found in less than XX minutes are transferred to the next block.
Maybe, but you'd have to get a "big" pool operator to implement that ... it becomes quite a messy calculation of who's working harder on which particular block, who was luckier on which block, rolling averages over multiple blocks, timedepreciating share values to stop "pool hopping" attack, etc. Bottom line is, right now the little guys are losing out when a pool gets too big, their variance starts going up again.




grndzero


May 09, 2011, 04:49:32 AM 

Couldn't that "short block variance" be mitigated by calculating rewards/shares for multiple blocks instead of dividing them one by one? With a straight, proportional payout system it would simply mean that shares for blocks that are found in less than XX minutes are transferred to the next block.
Maybe, but you'd have to get a "big" pool operator to implement that ... it becomes quite a messy calculation of who's working harder on which particular block, who was luckier on which block, rolling averages over multiple blocks, timedepreciating share values to stop "pool hopping" attack, etc. Bottom line is, right now the little guys are losing out when a pool gets too big, their variance starts going up again. Lucky there's at least 4 other smaller pools to pick from, 5 if slush is back up and stable.

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



Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2044
Merit: 1000


May 09, 2011, 09:12:58 AM 

The pool is there to smooth out the variance. But if the pool is finding blocks too quickly then a smaller, proportional miner may not get that many shares of each short block found and variance starts to return again, and more luck is involved.
That's false. You'll have (proportionally) more variance per block but this is more than offset by the reduced variance in the number of blocks per time unit. I think that under some simplifying assumptions, the best way to reduce variance is to put all your mining in the largest pool, even if it is as high as 100% of the network. I'll need to do some calculations to verify this part.




marcus_of_augustus
Legendary
Offline
Activity: 2562
Merit: 1044


May 09, 2011, 09:38:10 AM 

The pool is there to smooth out the variance. But if the pool is finding blocks too quickly then a smaller, proportional miner may not get that many shares of each short block found and variance starts to return again, and more luck is involved.
That's false. You'll have (proportionally) more variance per block but this is more than offset by the reduced variance in the number of blocks per time unit. I think that under some simplifying assumptions, the best way to reduce variance is to put all your mining in the largest pool, even if it is as high as 100% of the network. I think you'll find you are false. You've discounted the granularity involved that the difficulty 1 share system of scoring is placing on the problem. The ultra short rounds that the big pools get more frequently are essential for reducing the variance but a small miner can easily have a big fat "NONE" sitting in the shares column from one of these rounds. Because they could not find a difficulty 1 share in the same time it took the pool to find the block, they have no way to participate in the pool's mechanism for reducing variance for these ultra short rounds. It is the ultrashort rounds that have a large effect in bringing the variance back in the miners favour. Otherwise they are only toiling away on the longer blocks and not sharing in the ultrashort ones where they can 'make up' lots of lost time.




[Tycho]


May 09, 2011, 09:41:18 AM 

The pool is there to smooth out the variance. But if the pool is finding blocks too quickly then a smaller, proportional miner may not get that many shares of each short block found and variance starts to return again, and more luck is involved.
That's false. You'll have (proportionally) more variance per block but this is more than offset by the reduced variance in the number of blocks per time unit. I think that under some simplifying assumptions, the best way to reduce variance is to put all your mining in the largest pool, even if it is as high as 100% of the network. I think you'll find you are false. You've discounted the granularity involved that the difficulty 1 share system of scoring is placing on the problem. The ultra short rounds that the big pools get more frequently are essential for reducing the variance but a small miner can easily have a big fat "NONE" sitting in the shares column from one of these rounds. Because they could not find a difficulty 1 share in the same time it took the pool to find the block, they have no way to participate in the pool's mechanism for reducing variance for these ultra short rounds. It is the ultrashort rounds that have a large effect in bringing the variance back in the miners favour. Otherwise they are only toiling away on the longer blocks and not sharing in the ultrashort ones where they can 'make up' lots of lost time. Actually he is right. Yes, a slow miner will see some "None"'s for short blocks, but sometimes he will hit such block too and it will be balanced out. I am sure about this.

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.



marcus_of_augustus
Legendary
Offline
Activity: 2562
Merit: 1044


May 09, 2011, 10:11:18 AM 

Yes, a slow miner will see some "None"'s for short blocks, but sometimes he will hit such block too and it will be balanced out. But can he ever make up for the 0.5 or 0.75 of a share, i.e. the partial share that he should have got for the ultrashort round? Maybe it will be balanced out, eventually. The bigger question is how long will it take to make back the losses on a bad run? In other words, what is the ultrashort block variance for a small miner? Remember the primary idea of the pool is to reduce the variance for a smaller miner




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2044
Merit: 1000


May 09, 2011, 10:40:08 AM 

Yes, a slow miner will see some "None"'s for short blocks, but sometimes he will hit such block too and it will be balanced out. But can he ever make up for the 0.5 or 0.75 of a share, i.e. the partial share that he should have got for the ultrashort round? Maybe it will be balanced out, eventually. The bigger question is how long will it take to make back the losses on a bad run? In other words, what is the ultrashort block variance for a small miner? Remember the primary idea of the pool is to reduce the variance for a smaller miner I've spent a lot of time pondering variance of pool payouts. I don't think I'm wrong. All my calculations work on the share level and I definitely did not disregard share granularity. I can bring out the heavyduty math if you'd like, but the calculations involved are very easy to understand (if you know a bit about Poisson processes) yet very cumbersome to communicate, so I don't think this is worth the trouble. Let's say a small miner mined for an hour and got 1 share. It doesn't matter if the pool got one block or two in that time, he still has 1 share in a single block. Since we know nothing else about this block, the amount of shares in it is distributed exponentially and the participant's payout will have a given mean and variance, which are the same in both scenarios. If the miner has a significant portion of the pool it becomes more complicated, but it's complicated in the direction of further favoring larger pools. For a proportional pool, in the limit where the miner has a negligible portion of the pool, his variance per share submitted is p^2(1p+ln(p))/(p1), and this is additive in the number of shares (p = 1/difficulty). It does not depend on any other factors. When the miner has a larger share of the pool his shares become correlated and his variance increases, so it's better to be in a larger pool. Of course, it is my opinion that people should start using hoppingproof scoring methods instead of proportional (and I'll once again debunk the myth that they are in some ways disadvantageous for small miners).




marcus_of_augustus
Legendary
Offline
Activity: 2562
Merit: 1044


May 09, 2011, 11:04:52 AM 

Okay, write it up (sounds like you've done it mostly anyway) and I'll take a look ... I'm interested how that works, if nothing else. Doesn't have to be flash, just the meat.
And your basic contention is that smaller miners are better off in bigger pools?
(This would be a big issue if the network is driven towards everybody mining for the same pool.)




[Tycho]


May 09, 2011, 11:14:49 AM 

And your basic contention is that smaller miners are better off in bigger pools? We are trying to say that those supershort blocks are harmless for slow miners. The pool doesn't needs to be the only one.

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.



Meni Rosenfeld
Donator
Legendary
Offline
Activity: 2044
Merit: 1000


May 09, 2011, 11:58:09 AM 

Okay, write it up (sounds like you've done it mostly anyway) and I'll take a look ... I'm interested how that works, if nothing else. Doesn't have to be flash, just the meat.
And your basic contention is that smaller miners are better off in bigger pools?
It's the other way around. For tiny miners it makes absolutely no difference what is the size of their pool. It's the bigger miners that are better off in a bigger pool. Let's say a miner submits a share at a random point in time. Let A be the event the the share was submitted for a given round, and X the eventual number of shares in this round. Then $P(X=x) \propto p(1p)^{x1}$ (exponential distribution) and $P(AX=x) \propto x$ (the more shares in a round, the higher its chance to include a given share). By Bayes' formula, $P(X=xA) \propto P(X=x)P(AX=x) = p(1p)^{x1}x$. Summing for x>=1 gives $P(X=xA) = p^2(1p)^{x1}x$. The payout received for this share, in units of block reward, is 1/x. So the expected payout is $\sum_{x=1}^{\infty}p^2(1p)^{x1}x/x=p$, as expected (pun unintended). The expectation of the squared payout is $\sum_{x=1}^{\infty}p^2(1p)^{x1}x/x^2=p^2\log p/(p1)$, so the variance is $p^2(1p+\log p)/(p1)$. As you can see, this does not depend on any additional factors such as the size of the pool. When several shares are submitted, if the miner is tiny then they will be uncorrelated and their variance is additive. As the pool becomes smaller the variance for the miner increases. If you're not convinced this accurately models the situation (well, it doesn't, but it doesn't deviate in ways that are relevant for this discussion), you can write a simple computer simulation of the dynamics and see that the variance is smaller in a larger pool. (This would be a big issue if the network is driven towards everybody mining for the same pool.)
It is. There are threads for discussing this problem.




