Author

Topic: What's best for Deepbit is best for Bitcoin (Read 3288 times)

donator
Activity: 2058
Merit: 1054
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(1-p)^{x-1}$ (exponential distribution) and $P(A|X=x) \propto x$ (the more shares in a round, the higher its chance to include a given share). By Bayes' formula, $P(X=x|A) \propto P(X=x)P(A|X=x) = p(1-p)^{x-1}x$. Summing for x>=1 gives $P(X=x|A) = p^2(1-p)^{x-1}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(1-p)^{x-1}x/x=p$, as expected (pun unintended). The expectation of the squared payout is $\sum_{x=1}^{\infty}p^2(1-p)^{x-1}x/x^2=p^2\log p/(p-1)$, so the variance is $p^2(1-p+\log p)/(p-1)$.
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.
hero member
Activity: 742
Merit: 500
And your basic contention is that smaller miners are better off in bigger pools?
We are trying to say that those super-short blocks are harmless for slow miners.

The pool doesn't needs to be the only one.
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo

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.)
donator
Activity: 2058
Merit: 1054
Quote
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 ultra-short 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 ultra-short 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 heavy-duty 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(1-p+ln(p))/(p-1), 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 hopping-proof scoring methods instead of proportional (and I'll once again debunk the myth that they are in some ways disadvantageous for small miners).
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
Quote
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 ultra-short 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 ultra-short block variance for a small miner?

Remember the primary idea of the pool is to reduce the variance for a smaller miner
hero member
Activity: 742
Merit: 500
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 ultra-short 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 ultra-short 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.
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
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 ultra-short 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 ultra-short ones where they can 'make up' lots of lost time.
donator
Activity: 2058
Merit: 1054
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.
sr. member
Activity: 392
Merit: 250
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, time-depreciating 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.
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
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, time-depreciating 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.
full member
Activity: 518
Merit: 100
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.
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
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 pay-per-share 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 ... 1-2 hours, so that their share of the pool is well-represented 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.
legendary
Activity: 1232
Merit: 1076
-----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
member
Activity: 336
Merit: 10
Computta Mine Your Own BTC
hero member
Activity: 672
Merit: 500
BitLotto - best odds + best payouts + cheat-proof
BTW, this is not genjix (I didn't realize I was signed into his account)
LOL what?  Huh
sr. member
Activity: 406
Merit: 250
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?
hero member
Activity: 742
Merit: 500
legendary
Activity: 1232
Merit: 1076
BTW, this is not genjix (I didn't realize I was signed into his account)
legendary
Activity: 1232
Merit: 1076
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 'de-monopolize'. 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 non-technical noob, but please let me know why this disparity exists.
Jump to: