Every 4 years the Bitcoin reward halves, this creates a significant event in the mining community where people's operation suddenly becoming unprofitable, this may cause some unpredictability and instability in the bitcoin ecosystem.

Why isn't this reward smoothed so it is a function of the block number, no major jumps, just a slow decrease in the bitcoins mined each block?

I've been thinking out how to reduce any Capital Gains Tax that someone is liable to pay.

Lets say I bought 100 bitcoins for £1 they would now be worth £40K.
Assuming I'm already in a high income tax bracket, so the first £10K is part of my CGT allowance and the £30K is liable to tax at 28%.
But these taxes are only due when I realise my gains, ie. sell the coins.
So when I sell I would end up with £31.6K

So....
If I make a sequence of many bets with this capital, betting the whole amount through Satoshi dice or Just-dice.
(on just-dice this would probably be 1000 bets of 0.1 Bitcoins at 98% chance of winning)
I should end up with around 99 Bitcoins having lost around 1% due to the 'house edge' this would amount to £39.6K.

But winnings are not subject to Capital Gains Tax, and as all my Bitcoins are now the proceeds of gambling I don't need to pay?
   http://www.hmrc.gov.uk/cgt/intro/when-to-pay.htm#1

I guess this situation hasn't occurred before because any gains in other instruments (stocks etc) need converting into fiat before they can be gambled, and of course that triggers a taxable event, in this case it never becomes taxable.

Thoughts?

I'm trying to build a some depth data for MtGox, actually I only need around 10 values deep each side of the spread.

Gox seems to build the full depth data periodically, so its is often >20minutes old. (This seems the same for all the API versions).
The streaming websocket sends data in real time which I can apply to this full depth data, but this leaves a gap of depth updates between the time of gox full depth updated and when my program starts running.

I only see one option, and that is to run a process permanently that stores the streaming data, and once I get a full depth file that returns timestamps beyond the earliest streaming data I have stored, I can
  1) Make my initial depth hash equal to the full depth data file
  2) Then apply the streaming data

I must be missing something obvious, Isn't there an easier way?