BombaUcigasa
Legendary
Offline
Activity: 1386


June 13, 2011, 12:18:25 PM 

It has no effect on the payout from this pool. But once the payout from this pool, due to the length of its current round, is too low, you hop to a pool where it's higher.
Right. So you benefit by ditching the pool with a way longer round (so your investment in that pool is higher considering the time you put in, but still low considering what you could have gotten if you stayed) to a pool that found a new block. The only drawdowns to this method is when you have to switch between pools that still haven't finished a round and you go back and forth, and when you go into a fresh round, but because you stay too long in the fresh round pool, the other pool you ditched could end the round has a shorter round which is worth more than the long one, for which you don't get anything because you left).






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

drlukacs


May 01, 2013, 02:12:30 AM 

Raulo, you have a mathematical error on page 1, in equation (4). Your \xi depends on n. Consequently, you cannot pass to limit only in part of the expression. The expression q:=1 (1/2^32* D) is a real number < 1. Consequently, Q(n)=q^n >0 as n > \infty. This makes perfect sense, because the probability that you will "almost surely" (in the sense of probability theory) find a block if you wait long enough (infinitely long).




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1890


May 01, 2013, 06:49:29 AM 

Raulo, you have a mathematical error on page 1, in equation (4). Your \xi depends on n. Consequently, you cannot pass to limit only in part of the expression. The expression q:=1 (1/2^32* D) is a real number < 1. Consequently, Q(n)=q^n >0 as n > \infty. This makes perfect sense, because the probability that you will "almost surely" (in the sense of probability theory) find a block if you wait long enough (infinitely long). It's not an error, though tricky and somewhat unclear. He is assuming that \xi is constant while n and D are variable. For \xi=2, for example, he is considering a case that the hashes calculated are twice the average needed; he then considers what happens when D, and correspondingly n, go to infinity (continuous case). In this case the chance of not finding a block is indeed exp(2).




drlukacs


May 01, 2013, 01:08:23 PM 

It's not an error, though tricky and somewhat unclear.
He is assuming that \xi is constant while n and D are variable. For \xi=2, for example, he is considering a case that the hashes calculated are twice the average needed; he then considers what happens when D, and correspondingly n, go to infinity (continuous case). In this case the chance of not finding a block is indeed exp(2).
So, is there an implicit assumption that n and D are linearly related? You see, I have no problem with the observation that finding a block has a Poisson distribution. But the "proof" provided as it stands is simply wrong, unless D is a function of n, and \xi is the limit of their ration when n tends to infinity.




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1890


May 01, 2013, 03:00:21 PM 

It's not an error, though tricky and somewhat unclear.
He is assuming that \xi is constant while n and D are variable. For \xi=2, for example, he is considering a case that the hashes calculated are twice the average needed; he then considers what happens when D, and correspondingly n, go to infinity (continuous case). In this case the chance of not finding a block is indeed exp(2).
So, is there an implicit assumption that n and D are linearly related? You see, I have no problem with the observation that finding a block has a Poisson distribution. But the "proof" provided as it stands is simply wrong, unless D is a function of n, and \xi is the limit of their ration when n tends to infinity. The assumption is explicit = \xi is defined as n / (2^32 D), meaning that D = n / (2^32 \xi). And yes, in this calculation n and D both go to infinity at a specified ratio \xi. The assumption that \xi is fixed was not explicitly written but it follows from context. D doesn't have to "go to" infinity in real life for the calculation to show that if D is sufficiently large, then for any n the probability of not finding a block is roughly exp (  n / (2^32 D)).




camaro69327
Jr. Member
Offline
Activity: 59


May 03, 2013, 12:09:31 AM 

June 13, 2011, 12:18:25 PM <<<<WTF last post in this thread.
Posted on: May 01, 2013, 02:12:30 AM Posted by: drlukacs
So why did you resurrect a dead thread on cheating?? Most pools conteract this...

BTC : 1CcWoADqDtn5R1uL2TmTFw8CFtvLCqeW2j



drlukacs


May 03, 2013, 01:13:29 AM 

June 13, 2011, 12:18:25 PM <<<<WTF last post in this thread.
Posted on: May 01, 2013, 02:12:30 AM Posted by: drlukacs
So why did you resurrect a dead thread on cheating?? Most pools conteract this...
I was thinking about what is the most "fair" reward system. I was interested on what others have written about the topic. Meni's paper on the topic (which I have yet to finish reading) struck me as more deep and thorough. I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm that makes hash rates more even would actually benefit the entire community.




organofcorti
Donator
Legendary
Online
Activity: 1904
Poor impulse control.


May 03, 2013, 03:53:22 AM 

June 13, 2011, 12:18:25 PM <<<<WTF last post in this thread.
Posted on: May 01, 2013, 02:12:30 AM Posted by: drlukacs
So why did you resurrect a dead thread on cheating?? Most pools conteract this...
I was thinking about what is the most "fair" reward system. I was interested on what others have written about the topic. Meni's paper on the topic (which I have yet to finish reading) struck me as more deep and thorough. I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm that makes hash rates more even would actually benefit the entire community. I'm not sure how your last comment relates to the strategy suggested by Raulo in his paper.




gyverlb


May 03, 2013, 03:10:50 PM 

June 13, 2011, 12:18:25 PM <<<<WTF last post in this thread.
Posted on: May 01, 2013, 02:12:30 AM Posted by: drlukacs
So why did you resurrect a dead thread on cheating?? Most pools conteract this...
I was thinking about what is the most "fair" reward system. I was interested on what others have written about the topic. Meni's paper on the topic (which I have yet to finish reading) struck me as more deep and thorough. I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm that makes hash rates more even would actually benefit the entire community. I'm not sure how your last comment relates to the strategy suggested by Raulo in his paper. Terracoin retargets it's difficulty on each block (unless it changed its algorithm recently: the dev has already pulled a 24h mandatory update out of his hat forking the chain like that). Some people are mining Terracoin only when it's more profitable than other coins: this has similar effects than the ones happening when a pool is hoppable...




Meni Rosenfeld
Donator
Legendary
Offline
Activity: 1890


May 03, 2013, 03:32:17 PM 

I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm that makes hash rates more even would actually benefit the entire community.
Not sure what you mean but IIRC the formulation in AoBPMRS treats difficulty changes properly, it will work even if the difficulty changes frequently.




drlukacs


May 03, 2013, 05:42:13 PM 

I am not sure if I would call it cheating. In the case of Teracoins, some kind of algorithm that makes hash rates more even would actually benefit the entire community.
Not sure what you mean but IIRC the formulation in AoBPMRS treats difficulty changes properly, it will work even if the difficulty changes frequently. The question was how I came to this topic. The answer is that I was looking for some kind of algorithm (or even implementation) to hop to a different coin, as opposed to a different pool, when the difficulty goes up.




