Quote from: jspilman on April 30, 2013, 06:46:50 PM

If you wanted to prevent the grandfather from spending the coins before the 18th birthday, you would use multisig.

Grandfather would pay into a multisig with his pubKey and his grandson's pubKey. Then grandfather could make the same locked spend from the multisig, which would become valid when the grandson was 18. The grandson would also sign with his key and broadcast when he's 18.

Forgive me because I'm still pretty new in raw transactions and how they work, so I'm a bit lost with that explanation. I'll try to re-explain it in my own words and if I make a mistake, let me know.

First a transaction is created that requires both the grandfathers and grandsons private keys to spend. Once that transaction is broadcast, then the grandfather signs a new transaction that has a time lock on it of the grandsons 18th birthday. This transaction isn't broadcast. The grandfather hands the transaction to his grandson, who can sign it on his 18th birthday and he is guaranteed that the grandfather hasn't spent the money yet, since he never signed the money away. Once his birthday hits, he signs it, and proves he now owns the coins, and they are his, and he can get the transaction into the blockchain.

Is this correct?

Personally, I am more interested in the other case (I'm not sure if both have to be combined) for it to work - the death condition. But it sounds like something similar could happen. A new tx is created that requires 2 people to spend out of. The transaction would require a 3rd party to sign the transaction for it to be accepted at that time. In particular, I'm interested in an escrow-like use case, where the address of the output changes based on an external state (oracle). One transaction to set up the multisig, then another transaction to allow either to cash in once the oracle decides it can be cashed in?