Bitcoin Forum
December 03, 2016, 10:04:49 PM *
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 [2] 3 4 5 6 »  All
  Print  
Author Topic: Analysis of Bitcoin Pooled Mining Reward Systems  (Read 32816 times)
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
August 04, 2011, 09:44:48 AM
 #21

No, that's not how I meant it.

You could include a package like hyperref (http://www.tug.org/applications/hyperref/), this should by default already create clickable references to every chapter + section as well as create a pdf index in the document.
Ok, how about the new version?

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
1480802689
Hero Member
*
Offline Offline

Posts: 1480802689

View Profile Personal Message (Offline)

Ignore
1480802689
Reply with quote  #2

1480802689
Report to moderator
1480802689
Hero Member
*
Offline Offline

Posts: 1480802689

View Profile Personal Message (Offline)

Ignore
1480802689
Reply with quote  #2

1480802689
Report to moderator
1480802689
Hero Member
*
Offline Offline

Posts: 1480802689

View Profile Personal Message (Offline)

Ignore
1480802689
Reply with quote  #2

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

Posts: 1480802689

View Profile Personal Message (Offline)

Ignore
1480802689
Reply with quote  #2

1480802689
Report to moderator
1480802689
Hero Member
*
Offline Offline

Posts: 1480802689

View Profile Personal Message (Offline)

Ignore
1480802689
Reply with quote  #2

1480802689
Report to moderator
1480802689
Hero Member
*
Offline Offline

Posts: 1480802689

View Profile Personal Message (Offline)

Ignore
1480802689
Reply with quote  #2

1480802689
Report to moderator
Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
August 04, 2011, 02:13:11 PM
 #22

Perfect, thanks a lot! Smiley

Makes it also much easier to navigate the document, right?

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
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
August 04, 2011, 02:26:36 PM
 #23

One good thing about writing documentation is that when you have to explain your models, you need to think about them more carefully. And sometimes you find out that one of them is wrong.

I used to think that the existence of pool-hopping causes non-hoppers to earn, in the worst case, 70% of the normal reward. But I've now added to appendix B a derivation of this result, and it turns out my original model is wrong and it's actually 56.5%, equivalent to a 43.5% fee (and I've now confirmed it by simulation). All the more reason for miners in proportional pools to reconsider.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Aexoden
Jr. Member
*
Offline Offline

Activity: 53


View Profile
August 10, 2011, 03:32:29 AM
 #24

Still looking forward to seeing more of this. I especially hope you go into the caveats of handling difficulty changes properly with each system.

1JrEZbuiK1BBakhtVo9PiMctNCEhtcQAR
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
August 10, 2011, 03:55:30 AM
 #25

Still looking forward to seeing more of this. I especially hope you go into the caveats of handling difficulty changes properly with each system.
I'll get to that too, eventually. But my already busy schedule just got a whole lot busier now that I've decided to attend the NYC conference. So it will take some time.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 23, 2011, 10:45:36 AM
 #26

Quote
Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.
Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?

You've just stated correctly that you cannot predict the future, but then said the past affects the future.

Simplest link to verify it: http://en.wikipedia.org/wiki/Gamblers_fallacy

I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.

Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)

Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.

Take this statement from Roulo's document:
Quote
It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%

Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
asher2
Jr. Member
*
Offline Offline

Activity: 34


View Profile
August 23, 2011, 11:08:34 AM
 #27

Quote from: kano
Quote
Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.
Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?

You've just stated correctly that you cannot predict the future, but then said the past affects the future.

No he didn't. He said the past affects your estimation for the future.

Quote from: kano
I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.

That is true. It is also obvious, which is why nobody is disputing it.

Quote from: kano
Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)

Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.

Take this statement from Roulo's document:
Quote
It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%

"a gain between 28% and 22%" - going from 28% to 22% is a LOSS, not a gain.

Quote from: kano
Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...

This is not correct. You cannot use the average number of shares (from any point) needed to find a block to determine the average length of a round from the start of the round given that the round is already in progress. This is the obvious point you made earlier.

sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
August 23, 2011, 12:19:15 PM
 #28

Quote
Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.
Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?

You've just stated correctly that you cannot predict the future, but then said the past affects the future.

What? If a round already has two million shares, and difficulty is two million, your estimate for the round is that it will be four million shares. The two million already mined are important.

Quote
Simplest link to verify it: http://en.wikipedia.org/wiki/Gamblers_fallacy

I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.

True

Quote
Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)

Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.

What? This isn't true at all. Statistics is not high school science. A single counterexample proves nothing. We are talking about what should happen over large timeframes.

Quote
Take this statement from Roulo's document:
Quote
It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%

Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...

I have no idea what you are trying to say here. But I am positive it doesn't make sense, because it is an indisputable fact that you make money by hopping proportional pools.

Let's say there are two pools, one with 0 blocks mined this round, and one with 10 million blocks mined. You are claiming it doesn't matter which one you mine.

If you are going to be 10% of the hashrate of each pool, and difficulty is 2 million, in theory if you choose pool A, you will make 200000 / 12000000 * 50  = .83 btc

If you choose pool B you will make 200000 / 5000000 * 50 = 5 btc.

Go back to my first point. That seems to be what you don't get. The number of blocks mined already does affect the average number of blocks that it takes the solve a block this round.
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
August 23, 2011, 12:51:00 PM
 #29

Quote
Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be.
Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement?

You've just stated correctly that you cannot predict the future, but then said the past affects the future.

Simplest link to verify it: http://en.wikipedia.org/wiki/Gamblers_fallacy

I'll put it this way:
Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first.
I might have to reword this sentence in a way which is less dramatic but also less ambiguous.

What I meant is that, if a future event is random and independent of the past, you can't predict it better than the prior probability.

But if the event is not independent of the past, you certainly can improve upon the prior.

"Number of shares remaining until round end" is independent on the past. "Eventual total number of shares at the end of current round" is certainly dependent on the past. At round start, "probability that the round will have >3D shares" is 5%. If 2D shares have already been found, this probability is 37%. If 2.9D have been found it's 90%, and if 3D or more have been found it's 100%.

And, pertinently, the eventual total number of shares at the end of current round (denoted N) is what matters, since your payout for every share you submit is B/N. If E[B/N] is less than what you could get per share elsewhere (which is B/D), you should mine elsewhere.

And I'll repeat the simple example - if 2D shares have already been found, then necessarily N>2D so E[B/N] < B/(2D), so you want to mine elsewhere.

Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)
So, if I say something which is true, and which was already said before many times, and I'm properly citing an influential paper about it, redoing the calculations myself and adding calculations and results which were never published before, then I'm "copying"?

Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false.

Take this statement from Roulo's document:
Quote
It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate.

Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22%

Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...
You'll have 5% of the shares. You'll have more than 5% of the reward because you will have more shares in short rounds than in long rounds.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Bitsinmyhead
Sr. Member
****
Offline Offline

Activity: 376


View Profile
August 24, 2011, 08:38:55 AM
 #30

Very nice so far. Can't wait to read the finished paper.
Thanks!

Trade Bitcoin using credit card and with 4:1 leverage at plus500.
Sign up through: http://www.plus500.com/?id=67176&pl=2 for €25 free, or become an affiliate here: http://www.500affiliates.com/?id=67176
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
August 25, 2011, 03:01:24 AM
 #31

Yet a simple example with 50% shows this to be false:
If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found)
During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ...

Kano, I think you're confusing efficiency over one round with efficiency over many rounds. Your example only works over one round, or many rounds where a pool finds a block at the exact same difficulty level.

The whole point to pool hopping is that with the type of random number we deal with here and a proportional payout, there is a way to maximise your payout by leaving early. The reward for shorter rounds will over time be greater for those who leave early than for those who leave later or not at all.

Take the extreme example of a pool hitting a 10x difficulty block. You don't know this will happen, but if you hop off even at 1*difficulty, you might have had 9 rounds worth of other PPS payouts by the time the round at the original pool starts again. You've submitted the same number of shares as you would staying at the original pool, but ended up with a much greater reward. The same applies to a less extreme example - even if the pool hits a 2*difficulty block and you hop at 1*difficulty, you'd get a full rounds worth from PPS.

The real mind twister for me is that even without hopping to PPS, even if you turn your miners off at some arbitrary hop point before then end of a round, efficiency for the submitted shares will always be better than 1.0 in the long run. In the short term, variability can hide this, though.

Hope that helps.



Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
August 25, 2011, 06:09:57 AM
 #32

The real mind twister for me is that even without hopping to PPS, even if you turn your miners off at some arbitrary hop point before then end of a round, efficiency for the submitted shares will always be better than 1.0 in the long run. In the short term, variability can hide this, though.
Not really that surprising. The expected gain per share decreases with the age of the round. If you stick through the whole round (and there are no other hoppers) the efficiency will be 1. So if you leave early, even if this "early" is pretty late, you'll always get more than 1.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
August 26, 2011, 09:44:32 AM
 #33

I haven't made much progress with this lately, partly because I was too busy inventing a new reward system. But I hope to be able to resume work soon.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
August 26, 2011, 09:48:51 AM
 #34

The real mind twister for me is that even without hopping to PPS, even if you turn your miners off at some arbitrary hop point before then end of a round, efficiency for the submitted shares will always be better than 1.0 in the long run. In the short term, variability can hide this, though.
Not really that surprising. The expected gain per share decreases with the age of the round. If you stick through the whole round (and there are no other hoppers) the efficiency will be 1. So if you leave early, even if this "early" is pretty late, you'll always get more than 1.

Yeh, hyperbole is not really my strong point.  Tongue

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
September 02, 2011, 03:20:27 PM
 #35

I've added a section and appendix about PPS, thus completing chapter 2.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
September 08, 2011, 01:03:09 PM
 #36

Due to real or perceived demand, I've written a complementary paper Summary of mining pool reward systems.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
farfiman
Legendary
*
Offline Offline

Activity: 1449



View Profile
September 08, 2011, 02:30:37 PM
 #37

All this math is way over most of our heads ( at least mine)

But the 2 simplest reward systems -PPS and Proportional are Implemented very nicely
by two of the bigger pools.

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof. (Basically possible on fast pools only)
ARSbitcoin  and their SMPPS seems to be very good  and so far has  "survived " having a negative Buffer for short periods.



"We are just fools. We insanely believe that we can replace one politician with another and something will really change. The ONLY possible way to achieve change is to change the very system of how government functions. Until we are prepared to do that, suck it up for your future belongs to the madness and corruption of politicians."
Martin Armstrong
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
September 08, 2011, 02:36:50 PM
 #38

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.
I doubt that, hoppers are just too lazy to hop it properly.

ARSbitcoin  and their SMPPS seems to be very good  and so far has  "survived " having a negative Buffer for short periods.
Patience, it will collapse eventually (unless something happens to the pool due to unrelated matters first).

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
September 08, 2011, 03:00:41 PM
 #39

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.
I doubt that, hoppers are just too lazy to hop it properly.

It's true. You can still hop it in exactly the same manner as before, it just is less effective. To make proportional hopper proof you need a delay that is longer than a round could ever conceivably be.

Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
September 08, 2011, 03:35:35 PM
 #40

BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.
I doubt that, hoppers are just too lazy to hop it properly.

It's true. You can still hop it in exactly the same manner as before, it just is less effective. To make proportional hopper proof you need a delay that is longer than a round could ever conceivably be.
Actually, I was thinking about hopping without using the pool's published stats at all. When a block is found on the network which is not by any of the transparent pools, assign a certain probability to it in being from each of the delaying pools based on their hashrate. Calculate expected efficiency for such pools based on these probabilities. When efficiency is higher than other pools mine there (this will usually be when several hidden blocks are found in a relatively short time).

And that's without using technical methods to figure out block origin, of which I know very little (something to do with network traffic, long polling, etc.)

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Pages: « 1 [2] 3 4 5 6 »  All
  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!