Bitcoin Forum

Bitcoin => Mining => Topic started by: genjix on May 09, 2011, 12:40:01 AM



Title: What's best for Deepbit is best for Bitcoin
Post by: genjix on 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 '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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: genjix on May 09, 2011, 12:40:36 AM
BTW, this is not genjix (I didn't realize I was signed into his account)


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: [Tycho] on May 09, 2011, 12:44:20 AM
Possible way to help with this situation:

http://bitcointalk.org/index.php?topic=7622.0


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: xenon481 on 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?


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: bitlotto on May 09, 2011, 12:50:31 AM
BTW, this is not genjix (I didn't realize I was signed into his account)
LOL what?  ???


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: PwrLeveld on May 09, 2011, 12:53:40 AM
LOL what?  ???
x2


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: genjix on 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


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: marcus_of_augustus on 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 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: anodyne on 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: marcus_of_augustus on 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, 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: grndzero on 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, 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: Meni Rosenfeld on 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: marcus_of_augustus on 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 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: [Tycho] on 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 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.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: marcus_of_augustus on May 09, 2011, 10:11:18 AM
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


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: Meni Rosenfeld on May 09, 2011, 10:40:08 AM
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).


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: marcus_of_augustus on 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.)


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: [Tycho] on 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 super-short blocks are harmless for slow miners.

The pool doesn't needs to be the only one.


Title: Re: What's best for Deepbit is best for Bitcoin
Post by: Meni Rosenfeld on 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(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.