Date for 25 BTC per Block

[molecular]

Isnt it rather simple? If a block is found every 10 mins and we only have currently around 1900 blocks left until reward drop. That would mean 316 hours left before the drop happens which is about 13 days.

i wanna know the minute it's set to halve

haha, you will know only after the fact. It's kinda like with radioactive decay: you never know exactly when shit happens and you can only make probabilistic assertions over periods of time.

HopefullyProbably probabilistic uncertainty is the only common property of reward dropping and radioactive decay. 

ftfy

[Nite69]

 - http://bitcoinclock.com/

This clock does not tell in which timezone it is. Two guesses; either local or UTC? Anyway, it should be noted on the site. No feedback address there?

[dserrano5]

This clock does not tell in which timezone it is. Two guesses; either local or UTC? Anyway, it should be noted on the site. No feedback address there?

I noticed that a couple of weeks ago. Fortunately now they added this "1 week, 4 days, 14 hours, 30 minutes", which is true wherever you are.

[jl2035]

http://serason.com/projects/emccharts/countdown.php

REWARD HALVE COUNTDOWN

Very cool... how accurate is this?

[Stephen Gornick]

Very cool... how accurate is this?

It's an estimate as it can't know either future hashing capacity or variance.

In 2011 there were adjustment periods with so much new capacity coming online that it took just 8 or 9 days to reach the next difficulty adjustment period.  (The fastest was in 2010, in under 4 days).    Later in October 2011, as a few miners were powering down it took 17 days to reach the next adjustment period.

But since early June there have been a dozen increases in a row though by relatively small amounts (near 10% or less), and so far the current one is about even with no increase or decrease apparent right now.

So with just about 10 days left, the resulting likely time range is narrowing.

If you are in the U.S., it is looking quite likely that the halving will occur on Wednesday Nov. 28th.    Though it is entirely possible that more capacity could come online and it occur on the 27th, or it could slow and it would be later on the 29th.    We could see an even earlier date if at the 11th hour here some ASIC capacity were to reach Bitcoin main net, but there's nobody saying that is likely to occur.   And I doubt many miners are powering down their hardware yet, so I don't think we'll see a slowing.

[helloworld]

This clock does not tell in which timezone it is. Two guesses; either local or UTC? Anyway, it should be noted on the site. No feedback address there?

I noticed that a couple of weeks ago. Fortunately now they added this "1 week, 4 days, 14 hours, 30 minutes", which is true wherever you are.

In fact, from looking at that along with the time, you can calculate exactly that the time shown is UTC.

[candoo]

bitcoinclock.com

[payb.tc]

bitcoinclock.com

lol, nice bump.

yes, the reward drop is in UTC, but i guess i can write that on the site...

[Bitcoin.Greece]

Reward-Drop ETA: 2012-11-28 22:58:41 UTC (4 days, 11 hours, 30 minutes)

[yogi]

Has anyone setup an officiial block party irc channel yet?

[wareen]

http://serason.com/projects/emccharts/countdown.php

REWARD HALVE COUNTDOWN

Very cool... how accurate is this?

It seems to be using 600 seconds per block, which makes it not very accurate until a few hours in advance. With the average of the last 100 blocks being about 570 seconds, the estimated time is currently ~5 hours off.

Current estimation with 570 seconds: Wed Nov 28 17:22:04 UTC 2012

[Stephen Gornick]

Current estimation with 570 seconds: Wed Nov 28 17:22:04 UTC 2012

Except we have one last difficulty adjustment coming before block 210,000.

Interestingly, however, the estimate for the next difficulty is at about the same level as the current difficulty.   

So barring any changes in mining capacity (or extreme swing as the result of variance) it is looking like the halving will occur Wednesday afternoon/evening (U.S. timezones)  near the midnight hour for much of Europe and early morning Thursday in Asia.

[jl2035]

ok... so aprox. 3 days left...

still don't know if we should celebrate this or not be happy at all

[Nite69]

It's an estimate as it can't know either future hashing capacity or variance.

In 2011 there were adjustment periods with so much new capacity coming online that it took just 8 or 9 days to reach the next difficulty adjustment period.  (The fastest was in 2010, in under 4 days).    Later in October 2011, as a few miners were powering down it took 17 days to reach the next adjustment period.

I think there is a minor flaw in the design of the bitcoin; in calculation differency, the change should be accounted, so instead of "changing diff to a value which would have gave 10 minute interval last 2 weeks" the rule should be "changing diff to a value which gives 10 minute interval, if the calculation power changes as last 2 weeks". Shortly, it should have been extrapolated. If so, the 25BTC day could have been calculated more accurately already 4 years ago.

But it's a minor flaw, current rule just adds some variancy and is just fine.

[Nite69]

ok... so aprox. 3 days left...

still don't know if we should celebrate this or not be happy at all

I think, thos who already have bitcoins, should celebrate. Those who does not have yet, should need not.
The price is already rising.. ;-)

[dooglus]

I think there is a minor flaw in the design of the bitcoin; in calculation differency, the change should be accounted, so instead of "changing diff to a value which would have gave 10 minute interval last 2 weeks" the rule should be "changing diff to a value which gives 10 minute interval, if the calculation power changes as last 2 weeks".

I'm not convinced.  I think it's possible that your scheme could result in a less stable difficulty, with the difficulty adjustment continuously overshooting, overcorrecting.  Like watching a novice trying to steer a boat.

[jgarzik]

I think there is a minor flaw in the design of the bitcoin; in calculation differency, the change should be accounted, so instead of "changing diff to a value which would have gave 10 minute interval last 2 weeks" the rule should be "changing diff to a value which gives 10 minute interval, if the calculation power changes as last 2 weeks".

I'm not convinced.  I think it's possible that your scheme could result in a less stable difficulty, with the difficulty adjustment continuously overshooting, overcorrecting.  Like watching a novice trying to steer a boat.

From a macro perspective that's precisely what happens anyway.

Just like anything in nature, or markets; there is never an equilibrium.  Any appearance of such is simply a frozen snapshot in time, that doesn't reflect reality seconds before or after the snapshot was taken.

Equilibrium is forever sought, never attained.

[payb.tc]

I think there is a minor flaw in the design of the bitcoin; in calculation differency, the change should be accounted, so instead of "changing diff to a value which would have gave 10 minute interval last 2 weeks" the rule should be "changing diff to a value which gives 10 minute interval, if the calculation power changes as last 2 weeks".

I'm not convinced.  I think it's possible that your scheme could result in a less stable difficulty, with the difficulty adjustment continuously overshooting, overcorrecting.  Like watching a novice trying to steer a boat.

From a macro perspective that's precisely what happens anyway.

Just like anything in nature, or markets; there is never an equilibrium.  Any appearance of such is simply a frozen snapshot in time, that doesn't reflect reality seconds before or after the snapshot was taken.

Equilibrium is forever sought, never attained.

true, but nite's suggestion would amplify changes in difficulty. for example let's say the network hashrate doubles and blocks are solved every 5 minutes. we would have a huge difficulty adjustment sure, but under nite's system, it would assume the network hashrate was going to double *again*.

[Nite69]

true, but nite's suggestion would amplify changes in difficulty. for example let's say the network hashrate doubles and blocks are solved every 5 minutes. we would have a huge difficulty adjustment sure, but under nite's system, it would assume the network hashrate was going to double *again*.

It would 'make things worse' on cases when first hashrate is first increasing and the suddenly starts decreasing or vice versa.
However it would make things go better when hash rate increases or decreases steadily or stays constant. And this case is 99% of the time..

Ie, if the hashrate has doubled, we have a *good reason* to assume it will most likely double again in the same time.

Technically addition would be very simple, just add "+ delta hashrate" to the formula.

[jl2035]

200 blocks left... It can happen tomorow..