Quote from: Gavin Andresen on October 04, 2012, 07:02:44 PM

Quote from: jl2012 on October 04, 2012, 05:25:06 PM

However, if the exchange is completely disappeared, the BTC in the multi-sig accounts will be lost forever. Therefore, we need some "emergency exit mechanism". When the multisig account is setting up, an additional condition is added: (e.g.) "After 1 Jan 2013, the coins in this account can be spent by signature of key U only".

If you held a pre-signed transaction that sends the funds back to you with a lockTime of 1 Jan 2013 that would work.

Lets see... thinking out loud...

Start by asking the exchange for a brand-new public key to use for their half of the 2-of-2 transaction. Call the send-coins-into-2-of-2 transaction "F" (for Fund).

You create and sign that transaction, but don't broadcast it yet.

Use it's transaction id to create a second, one-input-two-signature, lockTime=1/1/2013 transaction that refunds the coins to you. Call that "R" (for Refund).

Send R to the exchange and ask them to sign it using that brand-new public key they gave you. The exchange checks the lockTime and then returns R and the signature to you. You check the signature, and if it is good, broadcast F (and keep the half-signed R someplace safe).

If 1/1/2013 rolls around and you want your coins back, you sign your half of R and broadcast it.

I'd have to think a little harder than I want to right now about whether or not signing R knowing only txid==HASH(F) opens up the exchange to attacks. I can't think of any, but the exchange providing a signature when it doesn't know the details of exactly what it is signing makes me nervous.

You could send the unsigned R and the signed-but-not-broadcast F to the exchange and trust that the exchange will not broadcast F unless they agree to sign R.

I think holding on to pre-signed-but-not-broadcast-yet transactions is a technique "we" don't think about enough.

I read the previous discussion at https://bitcointalk.org/index.php?topic=6439.0 and https://bitcointalk.org/index.php?topic=1786

Satoshi rejected the idea of OP_BLOCKNUMBER because of this:

Quote

If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime.

Yes, he is correct. So it is possible to incorporate the idea of nLockTime into script? For example:

1. The coin can be spent by 2-by-2 multisig with key E and key U at ANY TIME
2. If block height >= x, the coin can be spent by key U. The 2-by-2 multisig, however, is still a vaild way to spend the coin.

Therefore, the first condition is permanently true, regardless of block height. The second condition is always false before block height = x, and permanently true after.

It is better than using nLockTime because the user can deposit to the script hash at any time, without the need of sending nLockTime transaction back-and-forth and storing them. It also avoids the problem of asking the exchange to sign an unknown transaction