mutltisig for txns that are not currently valid, but may become valid?

[cunicula]

I'm still confused. Which of the following is impossible (or both)?

a) create the "address C" and have A and B each hold 1/2 the private key to this address. Allow them to sign txns moving inputs from "address C" without revealing the full private key to one another.
b) Allow A and B to sign txns moving inputs from address C when these inputs are not currently controlled by address C.

If (a) is impossible, I think options will be impossible. You will always be able to mine yourself out of your obligations.
If (b) is impossible, I think there is a simple workaround.

[I think once I understand multisig better, I will make a wiki entry targeted at explaining multisig to nonprogrammers.]
 

[Mike Hearn]

This isn't multi-sig specific. Have you read Satoshis paper? It might make things clearer.

It's (b) that poses the problem. Here's a quick overview of how the protocol works.

A transaction is a message that lists inputs and outputs. Each input is defined as a script called the scriptSig because it usually contains signatures, plus a sequence number, plus an "out point". An out point is a hash of a previous transaction plus an index, which is the index of the output on the referenced transaction. Each transaction output contains a script called the scriptPubKey, plus a value.

An address is just a convenience method for writing the contents of a scriptPubKey. When I say "send 10 coins to 17bo9Twd4hnf79bivt5HrbedmQNSgEL5CB" what I actually mean is "please put an output with value 10 and a script of OP_DUP OP_HASH160 17bo9Twd4hnf79bivt5HrbedmQNSgEL5CB OP_EQUALVERIFY OP_CHECKSIG into the block chain".

Other types of addresses can mean different output scripts (eg, multisig addresses). NB: above I wrote the script as containing the address in base58 form for conveniences sake. In reality scripts look a bit different, check blockchain.info to see how.

The inputs contain signatures. A signature consists of 3 things: a SIGHASH flag, and the r/s components of the ECDSA signature. Normally we say the r/s components are "the signature" and the SIGHASH thing is just a bit of extra data appended to the end, but from Bitcoins perspective all three are combined together. The SIGHASH flag states how the signature should be interpreted.

A signature is created over some data, so the question is, what data? It cannot be the raw transaction as you see it in the block chain because it would make it impossible to construct transactions - the act of inserting the signature calculated for the second input would invalidate the first.

Therefore signatures are calculated over modified forms of the transaction. The SIGHASH flag defines how the transaction is modified. The default is SIGHASH_ALL which means "sign everything except the input scripts". So the input scripts are deleted, then the transaction is signed. Now this obviously means you can sign each input independently without breaking the others. There are other SIGHASH flags but none of them allow you to avoid signing the outpoint. So you can't construct a "free floating" transaction and sign it, because when you modify the transaction in order to connect it to some output the signature breaks.

Is that any clearer?

[cunicula]

I think nLockTime is useful.
How about the following option contract as a use case?

A sells option to B

0) A and B send valuable deposits and a nominal fee to broker. They announce agreement to do steps (1)-(4).

1) A and B create 2 of 2 multisig address using one of A's addresses and one of B's addresses. Call the multisig address C. They tell broker about this address.

2) A signs 2 of 2 atomic txn moving 10 USDcoin from A->C and 0.1 BTC from B->A. A sends info to broker. Otherwise, broker confiscates A's deposit and returns deposit to B.

3) B signs 2 of 2 atomic txn moving 10 USDcoin from A->C and 0.1 BTC from B->A. B sends info to borker. Otherwise, broker confiscates B's deposit and returns deposit to A. Txn is broadcast and goes into block.

4) A signs 2 of 2 atomic txn moving 10 USDcoin from C->B and 1 BTC from B->A. A sends info to broker. Broker checks and sends info to B. Otherwise, broker confiscates A's deposit and returns deposit to B.

5) B signs 2 of 2 atomic txn moving 10 USDcoin from C->A. Txn has nLockTime component. B sends info to broker. Broker checks and sends info to A. Otherwise, broker confiscates B's deposit and returns deposit to A.

5) If (1)-(4) happen, broker returns deposits to both A and B.


Remarks:
a) Broker needs to be trusted with deposits for a brief interval while info is exchanged. Good news, he exits the picture completely with step 5. Without nLocktime, he would have to stay involved throughout the entire contract.
b) Txn can be broken into sequence of smaller txns if broker cannot be trusted with large deposits. High rep broker with one step sequence is equivalent to low rep broker with multi-step sequence. You would have to pay extra txn fees to do this. Without nLockTime, you could never split one txn into multiple steps. Therefore you would always need a high rep broker.
c) A and B will always carry out the agreement because loss of deposit exceeds any possible gain from cheating.
d) A or B could collude with broker. Collusion is detectable. Brokers that confiscate deposits are cheaters.
e) Competing brokers could spend money to ruin each others reputation. However, because of (b) a good reputation is not worth much. Just some savings on txn fees.
f) Since rep isn't worth much, anyone could become a broker. Brokering can be completely automated and just involve downloading a program. Brokering should be highly competitive.
g) (e) and (f) mean that sabotage of broker rep should never occur. [i.e. GLBSE MPex style feuding occurs because of a duopoly. In a competitive market it is a waste of time.]

Question:
Can broker check that A's and B's sigs are valid in steps (3) and (4)? If not, additional steps are necessary.

[cunicula]

Is that any clearer?

Thanks so much. I found that very helpful. I printed it out and will puzzle over it more.