Date for 25 BTC per Block

[MatthewLM]

If you could figure out the expected block height (for all time), the actual block height and the block rate over the last 2016 blocks then...

1. Add 2016 to the expected block height and take away the actual block height to get the number of blocks desired.
2. Determine the expected number of blocks to be created at the current rate.
3. Adjust difficulty to make expected rate hit the desired number.
4. Limit difficulty change to prevent large changes.

So if we have a difficulty change at block 2016000, and 2001 weeks have passed then we expect to be at block 2017008. Let's say over the last 2016 blocks, they were created at 8 blocks an hour. We need to reach block 2017008 + 2016 in two weeks time which is block 2019024. This is 3024 blocks more than 2016000, so we want 3024 blocks. This means we want a block creation rate of 3024/(14*24) an hour which is 9 blocks an hour. To try to get this rate we can adjust the difficulty by 8/9 = 0.889.

I probably explained that terribly but hopefully I got across the general idea. I didn't think about it too much and it is indeed academic, it doesn't matter.

[molecular]

2. Determine the expected number of blocks to be created at the current rate.

what is the "current rate", how do you calculate/measure it?

[dooglus]

2. Determine the expected number of blocks to be created at the current rate.

what is the "current rate", how do you calculate/measure it?

I think his scheme, now that I understand it, is to work out how long it is supposed to be until the next difficulty change, calculate the current hash rate from the time taken to find the last 2016 blocks, and set the difficulty such that if the hashrate stays the same over the next period as it was for the previous period then the next difficulty change happens when it 'should', based on 10-minute blocks from the start.

So in my hypothetical situation in which everyone starts mining 10 times faster due to ASIC or alien technology, and assuming that the previous difficulty adjustment happened when it should have (since we've been using Matthew's system for a while), the next adjustment will happen 14-1.4=12.6 days too soon, and so the next adjustment period needs to take 14+12.6=26.6 days.  We know that at the current rate it'll only take another 1.4 days, so we need to increase the difficulty by a factor of 26.6/1.4 = 19 to get back on target.

If the hash rate stays the same, and we do end up with the next adjustment happening on the 'right' day, the next adjustment will reduce the difficulty by a factor of 26.6/14 = 1.9x.

Overall we've increased by 19x and then reduced by 1.9, giving a resulting adjustment over 2 periods of 10x, which matches the increase in hashing power.  So we end up back on schedule, but at the expense of having a very slow 26.6 days during which blocks took an average of 19 minutes each to find.

Do I understand it right now?

[Nite69]

If you could figure out the expected block height (for all time), the actual block height and the block rate over the last 2016 blocks then...

1. Add 2016 to the expected block height and take away the actual block height to get the number of blocks desired.
2. Determine the expected number of blocks to be created at the current rate.
3. Adjust difficulty to make expected rate hit the desired number.
4. Limit difficulty change to prevent large changes.

So if we have a difficulty change at block 2016000, and 2001 weeks have passed then we expect to be at block 2017008. Let's say over the last 2016 blocks, they were created at 8 blocks an hour. We need to reach block 2017008 + 2016 in two weeks time which is block 2019024. This is 3024 blocks more than 2016000, so we want 3024 blocks. This means we want a block creation rate of 3024/(14*24) an hour which is 9 blocks an hour. To try to get this rate we can adjust the difficulty by 8/9 = 0.889.

I probably explained that terribly but hopefully I got across the general idea. I didn't think about it too much and it is indeed academic, it doesn't matter.

One morea cademinc thought; the difficulty should be calculated after every block, only input counted from a longer period (2 weeks?).
Ie for every block, count a difficulty which will result in expected block height in next 2 weeks (if hash rate stays the same).

[payb.tc]

the difficulty should be calculated after every block

yep, based on a rolling 2-week / 2016 block period.

[Nite69]

I said it before and I'll say it again: reward halving has been factored into the price of btc/usd for months now.

Let us wait 'till december has passed with judging this. I doubt it's been priced in correctly.

I agree with molecular; The production has just halved, if the demand stays the same and no extra reserves are being used, the price should double.

Of course, when the price rises, some reserves are taken in to markets which slows down the rise.

But this is just speculating. We'll see.

[maaku]

I said it before and I'll say it again: reward halving has been factored into the price of btc/usd for months now.

Let us wait 'till december has passed with judging this. I doubt it's been priced in correctly.

I agree with molecular; The production has just halved, if the demand stays the same and no extra reserves are being used, the price should double.

Of course, when the price rises, some reserves are taken in to markets which slows down the rise.

But this is just speculating. We'll see.

Yeah but guess what: you're not the only one who came to that conclusion. And lots of people bought-in anticipating the rise in price... which itself caused the price to rise. That's what I mean by being "already factored into the price." Look at the price 6 mo ago vs today. Hey, it doubled! Coincidence? Only partly.

[jl2035]

So, it ended up being November 28th in most every populated timezone.

Specifically, 2012-11-28 15:24:38 UTC
 - http://blockchain.info/block-index/322335/000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e

I was really expecting there to be some larger exchange rate volatility over the last few days.  I was expecting GPU miners to already have been selling in quantity on eBay.  

But it has been pretty quiet.

I think people expected asics to be shipped at least in november. That not being the case changed some things... many GPU miners will try for a few days more...

[MatthewLM]

Do I understand it right now?

Yes, I was thinking along those lines.

the difficulty should be calculated after every block

yep, based on a rolling 2-week / 2016 block period.

No reason why not to do this, it should keep the difficulty more stable this way because much could happen in 2 weeks.

[Nite69]

hmm.. did miners already start to turn off their machines.. 51 minutes since last block, 2 prevs are at 20 minute interval, block 210261

I think I'll keep mine running for a while.. but HEY! if the rate halves it will also halve the reward :-(


Edit: normal variance, I guess. F.ex. Slush hashrate does not seem to drop at all: https://mining.bitcoin.cz/stats/