Contracts

[dipsy]

I've been reading through Contracts on the Bitcoin wiki and just wanted to check something about one of the use cases: https://en.bitcoin.it/wiki/Contracts

Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first.

To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.

Forgetting the scenario where the grandfather dies for the time being, what happens if the grandfather spends his coins before the 18th birthday? Or are the coins "spent" by the grandfather and in a locked state so that they can only be accessed by the Grandson once the lock time has past?

Thanks!

[tomcollins]

I had this same question.  If the transaction is never broadcast, then surely he can spend his coins, then the transaction is invalid when the grandson tries to cash it in.  If he broadcasts it right away, then it must somehow be revoked or modified for the death claim to work.  Is this understanding correct?  But that would still create a small window where the old tx is modified and the new contract added, leaving a chance for a spend in that time.  My understanding of txs is still very rudimentary, so I feel like I must be missing an important piece of this.

[zedsdead]

I would like to hear how this can be resolved too.

Also, it looks like Ripple has a contract option too and it looks like it's being pushed more so than in Bitcoin.

[jspilman]

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.

[tomcollins]

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?

[jspilman]

Yes, that's right.

You can also do a 2 of 3 multi-sig and let the 3rd signer be the trustee of the estate.  If gramps kicks the bucket, the estate signs to release the funds early.