Topic: I dont get money (Read 14867 times)

Did you look at the Probability Table on that page?
Even if everybody in the world was running a client you'd still not be getting close to a 10⁻¹⁸ probability of a collision.
Admittedly this number is not zero but I never claimed it was impossible either.

But it is not an impossibility.  Therefore there is some probability, however small, that it could happen.

As the number of clients increases, so do the odds of this happening.  See the Birthday problem article for more info.

Everybody is working on a different problem so it is very unlikely anyone is trying to hash the same value.

I haven't checked, but I assume a single Bitcoin client doesn't try to hash the same value more than once.  So if I hash a value and generate an unsuccessful hash, the client won't try to hash that value again.  However, independent clients have no such knowledge of what values other clients have already hashed.  Therefore 1 computer running at 1000 hashes a second will find a successful hash more often than 10 computers running at 100 hashes a second because those 10 computers might be trying to hash the same value that will generate an unsuccessful hash.

Forgot to mention...

The odds of a bitcoin are not 1/2^256.

IFF the hash were truly random, and IFF we were seeking a certain 256bit number, those would be the odds.

A hash is not truly random.  But for our purposes in calculating the odds, to a reasonable precision, the hash is probably effectively random.  (Effectively random is a class of pseudo-random where it is random enough for the intended use.  For example, generating white noise or pink noise does not require very good pseudo-random, but cryptography to access your bank account should probably use a better pseudo-random source.)

And for bitcoin, we are not seeking a particular 256bit number, but rather a 256bit number whose leading bits are 0 (for a certain number of bits).  Since we don't care about the rest of the bits, the odds are considerably better.  If we need 'n' zero bits, then our odds are 1/2^n where n<256.

No.  In the coin example, the odds are not at all the same as "solving" bitcoin.  First off, in bitcoin the players are independent.  Your odds of winning are the same as my odds of winning, not 5/14 + 8/14 leaving 1/14 as nobody wins.  In bitcoin "nobody wins" is a huge portion instead of a very small minority portion.  It's essentially reversed.  I don't know the current odds of a bitcoin, but if, for example, the odds were 1/1,000,000 then if I could "flip" twice as fast my odds would effectively be 2/1,000,000.  Or in other words, first to flip 'tails' wins.  Do you want to flip twice per second or once per second?

And did I read bitcoin increments a seed value in the hash?  I suspect (back to that gut feeling again) that some seeds will be (are) a very long way away from an acceptable hash.  It might be better to use a random seed every time.

Assuming that bitcoin has not and will not generate a hash collision (different contents, same hash) then the first one to arrive at the proper seed will win.  Hence the importance of hash calcs/second.  (Of course, since more leading 0's are OK, there are multiple seeds which will result in an acceptable hash even without a hash collision.  Still, more tries/second are better.)

Just to clarify, I was referring to the coinflip experiment above. Where I hold only 1/3 of the coins in play but win more than 1/3 of the points availiable. (Which is not an illusion based on small sample size)

I am not in possession of the mystical bitcoin fountain.

That is an illusion based upon statistical probability over a small sample.  This is the gambler's dilemma where they are hoping to "beat the house" when the odds are clearly stacked against them.  Yes, some people do have "lucky" days and may do better than others over a short period of time.  People can and do win state-sponsored lotteries too.  That doesn't imply, however, that just because somebody had had some "lucky days" before that today will be the same.

In the case of Bitcoins, decreasing the number of hashes per second only drops the likelihood that you are going to find a successful hash that can generate a new coin block.

Before the last two difficulty adjustments it took my (4-year-old) mac laptop two weeks to generate any bitcoin.

So after the adjustments, I estimate it could take it 1-2 months to generate any.

Great work NLS! I was hoping you wouldn't work all that out until after you'd taken my bet

The next "paradox" is that since I'm doing 1/3 of the hashes and winning more than 1/3 of the time is it actually better to run fewer hashes/second?

Watched a YouTube video to learn the very most basic mathematics on probability and now I can calculate at least the coin flip experiment. If the coin flip experiment is representative of Bitcoin probability then I and my vague hunch are both wrong. Vague hunch is vague, so unfortunately my wrongness hasn't alleviated the hunch feeling. If the problem doesn't drive me crazy, I'll try to figure out whether there's a way to successfully demonstrate the hunch, but at this point the odds are stacked against me. After 100 iterations of the coin flip game, the person with one coin will have 38.7% percent of the points and the person with two coins will have 61.3% of the points. Here's a very simple mathematical demonstration.

This is a list of possible outcomes at each round.I have 8 chances out of 14 outcomes, which is 8/14 or 57.1428571%. You have 5 chances out of 14 outcomes, which is 5/14 or 35.7142857%. The chance of neither of us getting a point is 1/14, or 7.1428571%. To calculate the second iteration, just duplicate all the outcomes which results in 16/28 for me, 10/28 for you and 2/28 for neither of us. All of those simplify to the original result, demonstrating that the probability is the same no matter how many iterations. After a hundred rolls, I'll probably have 57 points, you'll probably have 36 points and neither of us got a point 7 times and this adds up to a hundred rolls. You ended up with 36 out of 93 total points between us, so you got 36/93 or 38.7096774% of the points. That's more than one third, so you win, I lose.

I'll take this bet. How much do you want to play for?

As I stated in two of the previous posts, I don't know the math for probability. I'm not claiming that my hunches are for sure correct or that I'm any kind of expert. My knowledge of probability is basically vague memory of this or that I may have heard from who knows where. I've got some hunches in my head and I was expressing them in the hopes that someone who knew what they're talking about would say, oh yeah, that the whatchamacallit principle and here's the simplified version of what you're trying to express. But then it turned into me trying to figure it out and without the proper mathematical knowledge, which is pretty much the equivalent of revving while in neutral. I didn't think you were being arrogant, I was just kindly making fun of you for suggesting that I could produce the math after reading or at least skimming over my posts. I'll probably never get around to the program just because I pretty much never program. Once in a blue moon I do program and most of those test programs wouldn't be difficult, but when you times the probability of me programming by the probability of me remembering this thread, the chance of them both of happening at the same time is next to zero.

Okay, I'm not trying to be some kind of genius or arrogant or anything. I'll just wait for the program.

Okay, I'm thinking of something orange. Something ooooooraaaange ... Do you give up? It's an orange!

Just show you the math? By golly, that's it! You're a genius! Here I was thinking that half a dozen vague examples would be much more clear than just showing the math.

No need to write a program imo, just show us the math for the actual odds.

Well, in that case I think it would be equal, but if you have one person with ten dice and one person who has one die and they usually have to roll many many times before getting the winning number, then the person with ten dice will win more than ten times more frequently than the person with one die. I'm more than happy to write a little demonstration progam, but it will take me a while to get around to it.

Here's another example. I have two coins, you have one. Each time one person gets tails and the other doesn't, the person who got tails gets a point. If you get tails and I get one tails, we flip a coin for the point. If you get tails and I get two tails, we spin a triangle to decide who gets the pont. I get two sides of the triangle and you get one. The deciding point coin flip and the triangle spin represent which tails landed first. We play for a hundred rounds. You win if you have at least one third the points when the game is over. You will lose almost every time.

I don't see any mathematical justification for that. I'd love to see the outcome of a program that does rolls like you're discussing.

What's the difference between one person rolling 10 dice (simultaneously, not sequentially) and ten people rolling one die? That's essentially what you're discussing.

I'm not familiar with the higher level math, but the idea is something like this, if you've got two people, one with a single one hundred sided die and the other with 100,000 one hundred sided dice and give them both 100 seconds to be the first to roll 00, and then repeat the exercise over and over again, the single die has the same probability to to roll a 00 as any other individual die, so he should win on average once every 100,001 iterations, but in practice, he will win much less often. I can't explain the specific mathematics, but I'm quite sure it is the case. It's certainly within the realm of testability if you had two machines that did rolls at the same rate and recorded the results. The person with the many dice will roll a 100 pretty much every roll, so even if the person with the single die rolls a 00 on the first roll, he'll then only have one chance out of how many total dice stop on 00 of having his die stop before one of the dies of the competitor stops on 00. The scale is totally off from Bitcoin, but I believe that the principle still applies. A client with 100,000 khash/s will generate more blocks per hash than a single client with 1 khash/s.

Edit: Changed the last sentence.

Part of the concept that I'm trying to express is that the probablity of a combined series of events as a whole is calculated differently than how the probability of a single equal event is calculated. Because Bitcoin is doing millions of hashes per second or every few seconds, that needs to be taken into account.

Marketmaker, I didn't mean to come across as hostile or unhappy. I wouldn't be surprised if there is some flaw - like I said, stats isn't my thing. I agree that some people don't realize that you're never "making progress" towards success - each roll of the dice has the same probability as the one before it.

NewLibertyStandard, khps should be fully accounted for by my math. The per-hash probability is very simple (p=target/2^256).

Across a small enough timespan (1 second), the probability is linear (the principle of local linearity):
p = (hashes / second) * (p of winning with one hash)
p = (khps*1000) * (target/2^256)

Across a longer timespan, the Poisson distribution comes into play, giving us that exponential term. The "Average" time on the calculator treats the problem like it's a linear distribution, so it will never be as accurate as the 50% and 95% numbers.

Basically, if you _don't_ generate at least one block in the 95% timespan, then you're very, very unlucky. The chances of generating a block in the 50% timespan are the same as flipping a coin and getting heads - even odds.