Is there any way to make an UTXO that cannot be spent until a certain block #? In bitcoin, each transaction has an nLockTime integer to specify the earliest allowed block number/time that the transaction can be added to the blockchain. In addition, each transaction input has an nSequence integer that could theoretically be used to update transactions and know which is the most recent (although this functionality is currently disabled). 

But is there a way to broadcast a transaction which is final and can be added to the blockchain immediately, but also make it so that its outputs cannot be spent until a certain block number/time? It seems like this would be a useful feature. For example, if I want to give my inheritance to be made available at the time my grandson/granddaughter turns 18, I don't think there is any way to do that in bitcoin except have someone hold the funds and give them to them at the time. Or if I wanted to give someone an allowance, I could just send funds at once for 3 months or so, and they would just show up in the son/daughter's wallet on a weekly basis.

So, just to double check, there's no way to do something like this in bitcoin, is there? Are there any security risks by allowing transactions like this? If there really isn't any way to do this, then maybe it's something to add to the hard fork wishlist. 

If there is no way to do this with Bitcoin right now, is it because there is a serious flaw with such a system where an UTXO could be added to the blockchain that is not YET spendable?

I can think of two ways that such a thing might be implemented. 


Supplement the bitcoin scripting language with OP_BLOCKINDEX and OP_BLOCKTIME opcodes, which just push the corresponding value onto the stack. These values would have to come from the block that spends the UTXO, though, not from the the block that included the transaction that created the UTXO. This would mean that any transaction outputs with these OP codes could not be spent with 0 confirmations, because these OPs would have no meaning in this context. (This method possibly adds too much complexity to the situation)
Or, similar to the nSequence field, we could add an extra few bytes to each output to denote when an output can be spent (block number/time). If not provided, it can be assumed to be 0.
No, there isn't currently any way to do what you describe without using a third-party oracle.

Yes, you may be able to do this relatively soon.  A soft fork has been proposed to introduce a OP_CHECKLOCKTIMEVERIFY op code` (CLTV), and what what I can tell it has strong support from the core dev team (but note that soft forks require miner support for implementation).

As Nick says, previous attempts were rejected because they proposed pushing the current block's height or time on to the stack like this:

&lt;pubkey&gt;       checksigverify  block           &lt;data&gt;    equalverify
&lt;your pubkey&gt;  compare to sig  current height  1000000   Only spend in block 1,000,000


Again, elaborating on what Nick said, the example transaction above would be valid in block 1,000,000---but if there was a chain reorganization, it might not be included in the new block 1,000,000 and so any transactions depending on it would be invalid.

The CLTV op code avoids this two ways.  First, it use the nLockTime value from the spending transaction rather than the block height or block header time value.  Since a transaction can only be included in a block if its nLockTime is equal to or greater than the current block height/time, this achieves the primary goal of allowing UTXOs that can't be spent until a particular time.

The other thing CLTV does is check values directly rather than pushing data to the stack.  This allows it to only implement a greater-than-or-equal-to check, so the transaction is always spendable after the specified height/time.

My guess is that the soft fork process to introduce CLTV will begin with Bitcoin Core 0.11, possibly sometime around July 2015.  (But, really, the core devs are unlikely to spend much time on CLTV until 0.10 gets released around January, so don't count on it.)