I dont get money

[jackraymund]

i dont get money
why?
http://img695.imageshack.us/img695/7048/omygy.png
in http://www.alloscomp.com/bitcoin/portStatus.php
Port 8333 is closed.
why?
how to open?

i enter this site http://portforward.com/english/routers/port_forwarding/Dlink/DIR-300/fpadvert.htm
download program and i can't use this

[ichi]

You won't even join the game of solving blocks until you've completely downloaded the current block chain (70,073 just now).  Then, you'll probably get a block every 2-3 weeks, on the average.  I don't have the formula at hand for estimating block generation rate from your Khash/s and difficulty, and it's multiply quoted on this forum.

[jackraymund]

ahh:/
im from poland i understand u
please reply me
i can or i can't
i have router in house

i have in router portforwarding i need a IP Address

[ichi]

You don't need to forward a port to generate bitcoins.

Check your router's manual re opening the port.

I connect via VPNs, so opening ports isn't an option for me.

[jackraymund]

i hceck my router and i need IP adress
http://a.yfrog.com/img16/9554/taaaj.png
i get my lan ip
192.168.0.100
and nothing :/

[nybble41]

You seem to be shifting the port numbers by one (8332 -> 8333; 8333 -> 8334). Perhaps that's the problem? Try putting 8332 in the first Private Port field.

[jackraymund]

OMG!!!!!!
http://img175.imageshack.us/img175/1858/taaa.png
Port 8333 is open.
@up
thanks u
@edit
i have 829khash/s and my balance is 0.00 why?
how many minutes at changing the state of my account?

[HarryS]

i have 829khash/s and my balance is 0.00 why?
how many minutes at changing the state of my account?

There is no "definite" formula. It takes time, so just run in the background and don't worry about it.

[jackraymund]

the border?
1 hours 1 day? 1 week?

[NewLibertyStandard]

It will take a very very long time to generate coins, but if you leave it running long enough, you will eventually get some bitcoins. Here's a calculator where you can get an estimate of how long it will take. The rate changes roughly every two weeks, so check the calculator again after a few weeks. Like I said, a very very long time. The easier way to get some bitcoins is to work for them or to just buy them.

[jackraymund]

if i have 768khash/s i need wait
Average   11 days, 18 hours, 1 minute
50%   8 days, 3 hours, 28 minutes
95%   35 days, 4 hours, 51 minutes
?! 24/7?

[NewLibertyStandard]

if i have 768khash/s i need wait
Average   11 days, 18 hours, 1 minute
50%   8 days, 3 hours, 28 minutes
95%   35 days, 4 hours, 51 minutes
?! 24/7?

Дa, 24 чaca в cyтки. Этo былo oчeнь лeгчe нecкoлькo нeдeль нaзaд, нo тoгдa Bitcoin был нa пoпyляpным вeб-caйтe, мнoгo люди нaчинaли иcпoльзoвaть eгo и тoгдa этo cтaлo oчeнь тpyднo вceм.

[jackraymund]

24/7
this not difficult for me:P
topic for close tnx evrybody

[lachesis]

The calculator is useful, but some people misunderstand how to apply the figures.

Suppose you're running 1000 kilo hash per second. The calculator says: 50% chance in 6 days, average is 9 days, 95% chance in 27 days.

Now if you run for 9 days and haven't generated anything, you might think you only have 18 more days to go until you are up to 95% chance (based on 27 days minus the 9 days you've already spent).

Uh uh, it doesn't work that way.

After you have spent some time generating hashes without gaining any coins, that time is lost and doesn't affect the future. So if you haven't generated any coins after 9 days, on average you need to wait another 9 days to generate coins, and you need to wait another 27 days from that point until you have 95% chance of having generated coins.

For the record I'm on 2000 kHash/s and have generated 50 coins in 9 days.

I wrote that calculator.

My understanding was always that (based on those numbers) in any 27 day period, you have a 95% chance of generating one or more blocks. In any 6 day period, you have a 50% chance of generating one or more blocks. I might have screwed up the math somewhere - I don't know stats that well. The formulae came from a friend of mine who read the design paper. Apparently it has some code for calculating block generation.
P(p,t)=1-e^(-pt)
Where p is the probability that you will win in one second: p=khps*1000*target/2^256, and t is the number of seconds.

So I solved for t:
t = -ln(1-P)/p

If anyone has a better understanding of the math and sees a mistake, let me know!

[NewLibertyStandard]

The calculator is useful, but some people misunderstand how to apply the figures.

Suppose you're running 1000 kilo hash per second. The calculator says: 50% chance in 6 days, average is 9 days, 95% chance in 27 days.

Now if you run for 9 days and haven't generated anything, you might think you only have 18 more days to go until you are up to 95% chance (based on 27 days minus the 9 days you've already spent).

Uh uh, it doesn't work that way.

After you have spent some time generating hashes without gaining any coins, that time is lost and doesn't affect the future. So if you haven't generated any coins after 9 days, on average you need to wait another 9 days to generate coins, and you need to wait another 27 days from that point until you have 95% chance of having generated coins.

For the record I'm on 2000 kHash/s and have generated 50 coins in 9 days.

I wrote that calculator.

My understanding was always that (based on those numbers) in any 27 day period, you have a 95% chance of generating one or more blocks. In any 6 day period, you have a 50% chance of generating one or more blocks. I might have screwed up the math somewhere - I don't know stats that well. The formulae came from a friend of mine who read the design paper. Apparently it has some code for calculating block generation.
P(p,t)=1-e^(-pt)
Where p is the probability that you will win in one second: p=khps*1000*target/2^256, and t is the number of seconds.

So I solved for t:
t = -ln(1-P)/p

If anyone has a better understanding of the math and sees a mistake, let me know!

I'm not sure about the math, but from my anecdotal experience with the calculator and my setup, bitcoins are generated a little bit faster than it estimates, but that may be because although I'd don't have a totally sick setup, I do have a decent setup which I try to keep well maintained to generate as many bitcoins as possible. Also, I have a theory that the amount of hashes to blocks generated isn't a straight line, but is rather slightly curved with the people with faster machines getting a slightly better rate of blocks per hash than people with slower machines. Kinda like the people who have worked out the probability to small lotteries and buy up certain percentages of tickets depending on the amount of tickets available and the size of the payout to get a probability advantage over the many individuals who buy a small number of tickets. It would be interesting to me to know whether people with different speeds of computers have different impressions of whether the calculator overestimates or underestimates.

[lachesis]

I wrote that calculator.
...
If anyone has a better understanding of the math and sees a mistake, let me know!

Lachesis, I wasn't trying to suggest any problem with your calculator, just with the way that some people interpret its output.

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.

[NewLibertyStandard]

I wrote that calculator.
...
If anyone has a better understanding of the math and sees a mistake, let me know!

Lachesis, I wasn't trying to suggest any problem with your calculator, just with the way that some people interpret its output.

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.

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.

[lachesis]

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.

[NewLibertyStandard]

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.

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.

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