I dont get money

[NewLibertyStandard]

]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.

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

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.

[1715189000]

1715189000

[1715189000]

1715189000

[1715189000]

1715189000

[1715189000]

1715189000

[1715189000]

1715189000

[FreeMoney]

]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.

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

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.

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

[NewLibertyStandard]

]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.

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

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.

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

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.

[Insti]

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'll take this bet. How much do you want to play for?

[NewLibertyStandard]

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.

Code:

Me	You	Tie	Score
TT	T
		Me	+1 Me
		Me	+1 Me
		You	+1 You
TT	H		+1 Me
TH	T
		Me	+1 Me
		You	+1 You
TH	H		+1 Me
		Me	+1 Me
		You	+1 You
HT	T
		Me	+1 Me
		You	+1 You
HT	H		+1 Me
HH	T		+1 You
HH	H		0

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.

[Insti]

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.

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?

[Gavin Andresen]

the border?
1 hours 1 day? 1 week?

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.

[RHorning]

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?

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.

[Insti]

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?

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.

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.

[agaumoney]

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?

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.)

[agaumoney]

I don't know the current odds of a bitcoin...

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.

[BlackEye]

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.

[Insti]

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.

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

[BlackEye]

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.

[Insti]

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.

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.