Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?
Not expected balance average. The balance it will reach eventually. When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse. ... But that collapse is the same with DGM also. Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares. DGM would also have the same problem of the balance getting low enough to cause a collapse. DGM doesn't have a balance. ... OK I don't get that one. Since the amount it pays is not exactly the block amount each time a block is found, it must have a balance. When it pays above the block amount (bad luck) that amount is obviously not covered by the block so must come from a 'balance' stored somewhere. Then when the pool gets a short block and pays less than the block amount, that is effectively increasing the balance. I'm simply looking at the payouts on Ozcoin - so unless they are doing it completely wrong, there must be a balance by the fact that the block amount doesn't match the payout amount. It's the operator's reserve. In bad luck the operator pays from his reserve, in good luck he builds up his reserve. You could call this "balance" if you insist but the difference from SMPPS is that the current reserve has no effect on the payment for future shares. That is, the reserve is not a miner-facing property and having a low reserve does not mean miners are better off elsewhere (especially since even in the event of bankruptcy, an honest operator will offer PPS cashout before discontinuing the pool). |
|
|
|
Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?
Not expected balance average. The balance it will reach eventually. When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse. ... But that collapse is the same with DGM also. Simple example, last week or the week before DeepBit has 26 blocks with an average across those 26 of 200% shares. DGM would also have the same problem of the balance getting low enough to cause a collapse. DGM doesn't have a balance. It is hopping-proof. Bad luck will cause reduced payouts for past shares but will not affect future shares. If the parameters are too aggressive the operator has a risk of losing his reserves, but this risk can be kept arbitrarily low with a choice of parameters. Also, assuming the operator keeps a cashout reserve (which he should), operator bankruptcy causes no direct losses to miners. |
|
|
|
Hey Meni! Coinotron's BTC pool rewards are now calculated using DGM  Great, enjoy! (And watch out for the high risk with your chosen parameters.) |
|
|
|
Secondly, your idea works and sounds good. Let's consider the starting result where p starts out at 0.01 and increases by some small fixed amount or percentage with every block until it reaches some long-term target.
The initial block finder would have mining power at block 2 equal to:
50^0.01/(50^0.01+9*0.000001^0.01)=11.7% of the network. The other 9 miners would each control 9.8% of the network.
Thus we no longer have a winner take all lottery. I agree that this is probably a better system than a winner take all lottery (though I still find the winner take all situation amusing). Moreover, it should be extremely simple to code this.
A better solution is to add an offset. Instead of giving stakeholders an improvement factor of s^p (s is the stake and p is the influence level of stake on mining), make it a factor of (a+s)^p where a is some constant. So early on, when nobody has a large stake, mining will be proportional to hashrate without much consideration of stake. Also later, even someone with low or no stake can still mine somewhat. |
|
|
|
Other than orphans (as I said with the 98.5% with 1.5% back into the fund that pays) what else will make the 'SMPPS' pool's expected balance average less than zero (plus some initial balance to help startup) over time?
Not expected balance average. The balance it will reach eventually. When a miner decides if to mine in a pool, his maturity time is affected by the balance now, not by the expected balance in the future. It takes just one point in time when the balance is low enough to cause a collapse. If the fee exactly matches the losses (so the operator doesn't get anything on average), this is Brownian motion and it is guaranteed to eventually be low enough, no matter how low is "low enough". If there is an additional fee which stays within the pool, the negative balance likely reached is inversely proportional to the extra. It will still cause large maturity time. The accumulated funds that will help the balance remain positive could have instead been handed out to miners. Also, this method is hoppable. Mining when the balance is high results in reduced maturity time, which means continuous miners will suffer from more than their fair share of increased maturity time. again I'm only referring to SMPPS for a base of discussion but using the description I mentioned above - in case there is any difference
You didn't specify what your method is. All *SMPPS match your description, the difference between them is how to distribute new funds. |
|
|
|
So I was thinking about DGM the other day coz I've swapped back to Ozcoin for a while ...
and I was thinking about how it compares to a modified version of PPS
... or more specifically what I guess is SMPPS though I'm not sure but what I mean is:
a PPS that pays (50/difficulty)*0.985 per share i.e. with a 1.5% pay back to the payout fund (to cover orphans)
and the pool effectively has outstanding debt that is paid later when the fund is less than the amount due to be paid at any payout time
Anyway is there a reason to use DGM instead of an appropriate modified version of PPS?
Since I'm thinking that the point of DGM is to match some modified PPS scheme, why not just use the much simpler scheme it is trying to match and have everyone be able to calculate their expected payments?
This is indeed very similar to SMPPS. SMPPS is broken as I've already written about at length. The short story is that when the debt grows large (which will happen with 100% probability), miners will have greatly delayed payments and thus move on to a different pool, causing the collapse of this one. Even under the unrealistic assumption that miners will not leave, they will just suffer unbounded maturity time. The purpose of a reward method is to balance variance, fees and maturity time, not to try eliminating any two for an extreme increase in the third. |
|
|
|
|
The only way is to delete your posts from that thread (and I heard even that doesn't always work).
In the planned forum software overhaul there should be better options for this.
I am now... leet. I think I will avoid posting for a while.
(Note to visitors from the future: Post count of 1337 is displayed as "leet").
|
|
|
|
|
Bonds are sold out for now.
|
|
|
|
File this one under "you can't win."
I fired up the new client after several days, the progress bar immediately went to 99%, and stayed there for the next ten minutes. I guess some people found the old behavior confusing, but of what use is this behavior?
I should call you "Lazarus". Welcome back. |
|
|
|
That is the point people who naively believe a market will flourish fail to understand.
99.9999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999% of the work in solving a block is .... solving the block. 0 transactions or 20,000 transactions the amount of work (and thus cost) is roughly the same.
So there is no economic value to exclude any paying transaction of reasonable value and no economic value in including free transactions so it is more like this.
I agree with your point, but way too many nines there. There is a tiny cost to including a transaction (verifying ECDSA sig, more bandwidth to broadcast the block) which is larger than a satoshi. |
|
|
|
In 4bi you're assuming one block is found in this time unit. This assumption probably does not affect the results, but It's safer to let X be a Poisson random variable with mean 1 and conf(2)=conf(1)+cX.
You are also right. The length of hashing rounds should be a Poisson random variable, whereas I made them deterministic. However, this should be coded differently from what you suggest. If you write it as conf(2)=conf(1)+cX, then this implies that the miner randomly misses the opportunity to participate in mining for a sequence of blocks. Instead, it should be that the miner can get multiple hashing opportunities before accumulating another confirmation. I will fix it when I get the chance. I was assuming each iteration corresponds to a time unit. If each iteration corresponds to a block being found somewhere then your simulation seems to be fine as it is. |
|
|
|
As far as I understand it, the more hashing power there is in the high fee pools, the better off everyone is, including you. If a sufficient amount of miners defect from high fee pools, you're worse off than you were originally, regardless of how profitable it seemed at first. This means that if the profits to be gained in the short term are not adequate enough, many miners will not bother to hop at all. In other words: My personal benefit from defecting is always higher than my share of the global benefit of me cooperating. I lose from other people defecting, not from me defecting.
You need some balancing factors to prevent that from happening. And they need to be stronger than the global incentive to defect. I agree. The balancing factor comes from the fact that miners will be constantly pool hopping in an attempt to increase profits. FreeMoney is correct that mining would probably become a bit more centralized from the effects of people selling hashing power to keep it simple. It's important to understand that the miners are not the only ones who control this. Pool operators can change their fee threshold and they hold fairly significant bargaining power. Also, as I already said, if everyone knows that all you get from defecting is a short term increase in profits, it isn't that straight-forward to calculate if you even want to do it. I still think that there would be a strong equilibrium where major mining businesses and pool operators constantly try to put the fees as high as they can. Not by some cartel or conspiracy, simply because that way everyone gets more profit. There will be defections and in the end users have a lot to say as well, if they're not willing to pay huge fees then it becomes very unprofitable to run a high fee pool and miners are forced to lower thresholds. In any case miners will always attempt to put the fees as high as possible, anything they can get away with. This will be balanced by the low fee pools and by what users are willing to pay but still, they will not stop trying which is exactly why I think that what I'm talking about does work. It's not short term vs. long term. It's not hopping between pools to increase profits. It's each miner vs. everyone else. If I'm a selfish miner who only cares about my own long-term profits, my total profits will be higher if I mine at a low-fee pool. Always. I don't hop. I stay in this pool forever. Going to a high-fee pool will not increase my profits, not the profits I have now and not the profits I will have at some future time. And while I'm permanently staying at the low-fee pool, I hope there will be suckers who mine at a high-fee pool and increase my profits. If there are no such suckers I'm screwed, but in this case I'm screwed either way, even if I chose to go to a high-fee pool. Without a protocol change, the only way to change this equilibrium is with an enforceable way to aggregate hashrate (such as an agent buying mining capacity as described by freemoney). Just think of it from the perspective of a mining pool operator or someone who runs a major mining operation. If they hold some bargaining power it makes sense to them to constantly change the fee threshold to a higher amount, for at least a little while and see if others want to do the same. Other operators see this and decide that well, we'll do it too. Thus the fees start going up and profits start increasing for everyone. Then we see defections and it starts getting worse again. Cycle restarts. In reality this cycle will actually be continuous and never ending, which creates a sort of equilibrium.
If we assume that everyone is selfish and that this is common knowledge, this won't happen, unless each pool individually is big enough to change the equilibrium. Of course, if some pools are altruistic (or at least superrational) or believe others are, this is a possibility. |
|
|
|
I know about the tragedy of the commons but let's just say that I've always been very skeptical about it, it really does not apply well to most real life scenarios. I understand what you're saying and maybe I'm the one who is clueless here but I'll try my best now to make sense of all of this.
In some cases tragedy of the commons is overcome when there are additional factors at play. It depends on the ratio between incentive to defect and the stabilizing forces. But I think it's much more prevalent than you think. Voting is a classic example. AFAIK voting rates in US are very low, and it is generally agreed that the total welfare would increase if everyone voted (the total effort of all people voting is justified by the election of a party which better addresses people desires). But for each person, the effect of his own vote on his own welfare is negligible, so most people pass. Another example is software. Would it not be better if instead of dealing with DRM, registration keys, closed platforms and so on, companies would allow anyone to download the software, specify a price, and receive payments on the honor system? If this was in place and everyone (who pay under the current system) paid, everyone would be better off. But everyone would be incentivized to spare himself this cost, which eventually results in the breakdown of this model and resorting to DRM. (Some people have offered software on an honor system, somewhat successfully, but mostly because of the novelty factor - it doesn't scale.) There are no doubt cases where it could have occurred, if society hadn't been able to redefine the rules to dispel it. People have been suggesting all sorts of factors that would mitigate the tragedy of the commons problem in Bitcoin mining, but I still doubt that they will be enough quantitatively. We need something about which we will be able to be much more confident. I don't believe that high fee miners will defect to low fee pools simply because it appears that they would get more by going there. In fact they get significantly less because by doing that users don't have incentive to pay high fees anymore.
To think about this in another way is to imagine that all miners will defect to the low fee pools. What happens then? Mining becomes unprofitable and some miners will again attempt to raise fee thresholds.
Again, if I am a small miner, the effect of my mining on the equilibrium is negligible. By going to a high-fee pool, I'm increasing the frequency of high fees by about 0.0001% (which I will also enjoy). If I go to a low-fee pool with twice the total reward, I increase my rewards by 100%. I would much rather that all other miners go to the high-fee pool; but whether they do or don't, I'm still better off at the low-fee pool. In other words: My personal benefit from defecting is always higher than my share of the global benefit of me cooperating. I lose from other people defecting, not from me defecting. (Unless I'm a sufficiently large miner.) You need some balancing factors to prevent that from happening. And they need to be stronger than the total incentive to defect. |
|
|
|
What happens is that major mining businesses who don't want to just quit, start raising their fee thresholds. This eventually creates a situation where you might only have 10% of total hashing power in pool z and everyone else has moved on to either the high fee pools or the medium fee pools.It's true that pool z gets the fees for everything but they only find 1/10 of the blocks. All users that appreciate speedy transactions will pay more than the minimum and 90% of those blocks do not benefit pool z in any way.
Who has moved on? Miners? You're confused about how mining and mining pools work. If a pool has N miners (suppose for simplicity all pooled miners have the same hashrate), then it finds on average N*a/D blocks per day, where D is the difficulty and a is a global constant. If the average reward per block is B, the average total reward per day is B*N*a/D, which is distributed among N miners, so each gets B*a/D on average. The only thing that changes between pools is B (based on their inclusion policy), so miners will always go to the pool with a higher B (which is the pool that includes all transactions). The fact that this pool is "only 10% of the total hashing power" has no effect on this. A smaller pool will have more variance, but since the all-inclusive pool pays the best, there's no reason it should be small. The end result is that pools which only include high-fee transactions will not be competitive, and 100% of the pooled mining hashrate will be in low-fee pools. And the point remains that although all pools would be better off if all pools accept only high-fee transactions, no pool would initiate a move to higher threshold (without being part of a cartel) because it will decrease its own profitability. Which, once again, is called "tragedy of the commons", or "prisoner's dilemma" in the 2-player case. I find it perfectly possible that all of the different pool classes can be profitable, except perhaps the one that only accepts minimum transactions. I'd imagine that at this stage a very large majority of users want to pay more than the minimum to make sure their transaction is at least in the next couple of blocks. Pool z gets a small share of that action.
It gets a share of that action proportional to its hashrate, like any pool. And in addition it gets a share of the low-fee action. Not less profitable, more profitable. Imagine if 80% of hashing power simply decided that they've had enough of these free transactions. Their mining hardware costs money, it requires work and they want some profit. Traditional block rewards are a fraction of what they were back in the day. They want to keep mining and supporting the network but it's simply unprofitable.
Now imagine that 80% changing their fee threshold from 0.001 to 0.01, effectively increasing the fees by 10. Now users have a choice, they can either send transactions with a 0.001 fee and wait on average for 50 minutes to be included in a block. Or they can add a 0.01 fee, which is still quite cheap, and make sure that their transaction is in the next block.
Yes, if 80% of hashrate forms a cartel and make an explicit agreement to play hardball, they will increase their profit. But even after the cartel is formed, members of the cartel are better off if personally they defect from the cartel and start accepting all transactions (unless the cartel enforces it somehow), as well as non-cartel members who will still accept all transactions. The cartel would have to crush competition by rejecting all blocks who do not conform to the cartel. And that is not a scenario I wish to happen. It's easy to think that everyone would just mine at the pool that accepts all transactions, because their blocks have the biggest rewards. Fact is that it just doesn't work like that. If everyone did that, we would be back to square one where mining is unprofitable. This is why there will be a sort of profitability index or "difficulty" for each pool, not just mining in general. If too many miners go to a low fee pool, suddenly users are not paying high fees anymore because there is sufficient hashing power in the low fee pools. Thus the profitability of all mining goes down. This is not in the interest of miners so it simply won't happen.
Now I'm sure you haven't read Prisoner's dilemma and Tragedy of the commons (the former is clearer, it refers to a 2-player case but the logic is the same). Every miner will act in his own self interest, not in the interest of other miners. Whatever other miners do, the most profitable thing to do is to defect (which in this case means accepting all transactions). Everyone will do that, and as you correctly state, we will be back to square one where mining is unprofitable. (And it's not necessary that everyone will do that, it's enough that someone will do that). This can be resolved if we change the rules so that the global interest is aligned with everyone's self interest. But this requires a coordinated effort, it doesn't happen spontaneously. |
|
|
|
In addition to only accepting transactions with a certain fee, miners might not even attempt to mine a block at all until it has enough in fees to be profitable.
Unless something else can be done with the hardware, it's quite possible miners will keep mining to avoid thermal cycles. Whether this will happen is TBD. 1) Plenty of people have reasons to get their transaction fully confirmed ASAP. For example, MtGox users. So, users will include a large transaction fee in hopes of convincing more miners to turn on to mine the block.
Tragedy of the commons, the contribution of a sender to confirmation time is everyone's, the cost of the included transaction fee is all his own. ie, the personal effect on paying a fee for the confirmation of your own transaction is negligible. They'd then likely send fee-only transactions in the next 5 blocks to make sure that the mining keeps up.
Even more tragedy of the commons, since they don't even get any preferential treatment for fees paid this way. But it would be interesting to find an incentivization scheme which does incentivezes the miners of the next blocks. 4) Businesses will contract out to certain miners to ensure that low priority transactions (such as low-value POS transactions where the person also provided their ID) get included in a semi-timely manner for a monthly rate (businesses love stability). MtGox already does this.
Explanation required. 7) Miners will have invested a good deal of money in specialized hardware to mine bitcoins. As a result, any attack that could potentially undermine Bitcoin would likely be met with the FULL force of ALL specialized mining hardware which will have been programmed by their owners to reverse the attack in order to protect their investment. As an added plus, we gain a huge security through obscurity benefit here since it'd be impossible for an attacker to predict how much mining power the whole network actually has until they've tried attacking it.
See also this thread. |
|
|
|
Block space is limited, as is the computing power to validate the signatures in the transactions. Right at the moment neither of these is really scarce, as understood by laymen, but they aren't unlimited either.
Block size currently has an arbitrary limit of 1MB. It is generally understood that when there are too many transactions it will be lifted or relaxed, so actually there is no real limit. (If a sufficiently tight permanent limit is set, we will not have this problem. But this of course could hurt scalability). The cost of validating signatures is negligible. To put it simply what will happen is this:
We will have a large number of pools and most likely many different p2pools as well. I will pull some numbers out of my ass to illustrate this, in reality the market will decide these numbers.
Pool x has a fee threshold of 0.1, meaning that they only accept transactions that have at least 0.1 bitcoins as a fee. This is the "high speed, high prices, low volumes" pool.
Pool y has a fee threshold of 0.05, which is "if you want decent speed but don't want to pay a premium" type pool.
Pool z has a fee threshold of 0.001, this is the "cheaper than the competitors, but slow as fuck" type pool.
Pool z will include all transactions with a fee above 0.001, which includes all transactions included by pool y, which in turn includes all transactions included by pool x. The total block reward in a block found by pool z will be higher than in pool x. The expected payout for mining at pool z is higher than in pool x. Nobody will mine at pool x. Once again - including transactions is cheap. You can include all of them (that is, those with fee higher than the tiny cost) and increase your profits. Everybody will do that, unless he is big enough to individually (or as part of a cartel) have a real bargaining power, which itself would be a problem. |
|
|
|
Meni pointed out that doubling hashing power doubles the immediate probability of mining a block. This is true. However, my system is dynamic. In my system, finding a block today tremendously decreases the probability of finding a block tomorrow. Due to this factor, returns to scale can only be evaluated as the average rate of finding blocks over a longer time period, not the one-off opportunity of finding a block now. If you mine a block, then you use up all of your coin-confirmations and the timing of your next block is delayed. Because of this effect, increasing hashing power exhibits decreasing returns. Once you mine a block you have to wait for your coin-confirmations to gradually recover before you can effectively mine again. There is a downside to hashing the block now because it decreases expected output in future periods.
It's quite possible that the fact that finding a block, as opposed to looking for one, requires consuming the coin-confirmations resource, was lost on me. 1) Take one hundred million draws from a uniform distribution on support of [0,1]; denote these as rand(i) where i indexes draws
2) Assume agent uses k unit of hashing power and c coins (each coin starts with 1 confirmation)
3) denote the conf(i) as the number of coin-confirmations in the account at time i; note that conf(1)=c
3) Assume that difficult is such that the probability of mining a block in one unit of time with 1 unit of hashing power and 1 coin-confirmation is 10^-8
4) Go through these draws sequentially as follows:
4a) If rand(1) < (10^-8)/(k*conf(1)^alpha), then a block is mined
4ai) Add one block to count of mining payoff
4aii) conf(2)=c
4b) If rand(1) > (10^-8)/(k*conf(1)^alpha), then the hash isn't good enough to mine a block
4bi) Assume someone else mines this block, so conf(2)=conf(1)+c
5) iterate this procedure through all 100 million draws
Are you sure that's your simulation? The line rand(1) < (10^-8)/(k*conf(1)^alpha) suggests that increasing k and conf(1) decreases the probability of finding a block. So either it's really (10^-8)*(k*conf(1)^alpha) and then it's ok (for now, see below), or it's rand(1) > (10^-8)/(k*conf(1)^alpha) and then it's wrong, or something weird is going on. Also, when you determine the probability to find a block, the value of k should not be raised to any power (this was my earlier point - twice the hashrate, twice the probability to find a block with a given number of coin-confirms). conf should be raised to the power beta since that's how you determine the target. In 4bi you're assuming one block is found in this time unit. This assumption probably does not affect the results, but It's safer to let X be a Poisson random variable with mean 1 and conf(2)=conf(1)+cX. |
|
|
|
I agree with kano. The Gambler's Fallacy isn't restricted to just discrete cases. It's exactly what you described - the belief that recent bad luck increases the chances of good luck. For independent events (such as finding blocks) this is false. The LLN doesn't work by anticorrelating proximate events, and the fallacious belief that it does is, once again, the gambler's fallacy.
Meni, I know exactly what you are getting at, and that is not what I intended with my original statement. I should have been more explicit what I was referring to. You're and kano are reading into what I said in one way, I meant it another. As our average shares per block is significantly higher than the expected value, over the next X blocks, where X is arbitrarily "large", our average shares will tend toward the median. The only way for that to happen is to have rounds whose total shares are near or below the median. That's why now is a good time to mine here for the next X blocks. I wasn't talking about this block, or the next, or the one after, etc. in my original statement. I talking about the next X blocks, even though I wasn't explicit in saying that. Now, seriously. I'm done. I need to study. I'm sorry, but this is still wrong. Yes, there will be rounds whose total shares are below the median. No, the frequency of such rounds over the next X blocks is not affected whatsoever by the fact that we've had recently some rounds with total shares above the median. No, now is not a better time to mine here than any other. It is instructive to understand that while (number of occurences / number of attempts) approaches the probability of occurrence for n->Infinity, (number of occurences - expected number of occurrences) does not approach 0, rather it increases in absolute variance for larger n. You don't need to discuss this further if you don't want. Either you take my word for it or, when you have the time, read up on the matter, gain some experience, run simulations etc. Man nice run of blocks
I know, right!? 99.95%, 99.99%, 98.24%, all in a row. Keep 'em coming! Let's not, the share ratio is way off. Although I did get 10% of the shares on 1 block. Hard to see the effect on payouts with dgm. It's pretty clear on the namecoin blocks though. Forget the share ratio. For every block found you get rewarded for shares you submitted in the past. In other words, more blocks per time unit = more money. |
|
|
|
There is an aspect of this which is textbook tragedy of the commons, but it's kind of abstract. The scarce public good being consumed is the bargaining power of miners. As long as miners have that power, they can demand enough fees to fund the mining required to secure the network. If a miner accepts low-fee transactions, he consumes this bargaining power (since then senders will have no reason to include fees) for his own benefit, making everyone worse off (miners who are now unable to collect fees, and Bitcoin users who will now not have a secure network). I don't think you quite grasp the way markets work. What you're describing makes no sense to me. The mining network will form a near-perfect market environment where some will have a business based on volume and some will base their business on higher prices and faster transactions. Miners won't just quit in the same way as they do now, if the fee they are accepting suddenly becomes unprofitable, they can simply change their fees to find a more optimal level. A more optimal level could just as well be higher, not necessarily lower. A miner can try to demand high fees, but if 99% of miners accept low fees, nobody will be willing to pay these high fees. You are forgetting that (unless limitations are placed), space for transactions is an abundant resource. It does not work like a market where participants manufacture a scarce product. The only thing to lose by including a transaction is bargaining power - which is everyone's, not just the individual miner's. If the mining community is too crowded compared to Bitcoin transaction counts (and to an extent price and difficulty as well, just like now), then some will quit mining and thus difficulty goes down meaning more blocks and thus more reward for everyone else (not as block rewards, but as transaction fees).
That's exactly the problem, miners will quit and the network will be less secure. |
|
|
|
Its me, Im bad luck Im telling ya, but I love this pool! LOL
And where did all the crazy hashrate come from the last 10hrs?!?!?!?!?
I believe the jump in hash rate is due to hoppers calculating that there's a high probability of us finding blocks. In other words, we're so down on our luck that there's bound to be a bright future. Or more correctly known as ... Gambler's Fallacy http://en.wikipedia.org/wiki/Gamblers_fallacyNo, not really. I was referring more to the law of large numbers. The numbers aren't large, it's Gambler's Fallacy. The Gambler's fallacy is more concerned with discrete cases or the following event. That was not my original point, and you are mistaking my intentions with a completely separate idea. Don't let the "large" in the name of the law fool you. The law of large numbers doesn't depend upon what you may think is a "large" number. In fact, the largeness is arbitrary. The law of large numbers simply states that "as the number of trials of a random process increases, the percentage difference between the expected and actual values goes to zero," If you really want to continue this debate, we can do so via PM. Although, this is about all I'm going to say about this for a while. I have an actuarial exam that I'm studying for. So, don't expect an immediate response from me. I agree with kano. The Gambler's Fallacy isn't restricted to just discrete cases. It's exactly what you described - the belief that recent bad luck increases the chances of imminent good luck. For independent events (such as finding blocks) this is false. The way the LLN works is not by anticorrelating proximate events, and the fallacious belief that it is is, once again, the gambler's fallacy. Of course, regardless of how you call it, the premise - that now is a better time to mine because we haven't found a block for a while - is wrong, and if it was true, the pool would be hoppable. You could also read up on Memorylessness. |
|
|
|
|
Show Posts
