Topic: mutltisig for txns that are not currently valid, but may become valid? (Read 2185 times)

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

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.

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?

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.]
 

Whether nLockTime is pointless or not has been argued several times before, I'm not sure it's worth going round that all over again. Maybe we should write up the previous discussions somewhere.

Suffice it to say, I do not think it is pointless, and apparently neither did Satoshi, as it's a part of the protocol. And yes, we're sure how transaction replacement should work. It should work as the code says it should work when you remove the "return true;" that makes that section of code dead.

cunicula, don't think of protocols in terms of addresses, you will just confuse yourself. Addresses are just  a hack to make pubkeys easier to write. Think in terms of inputs and outputs. Remember that signatures cover inputs connected outputs. You cannot sign a transaction that isn't connected to other transactions, so your proposal is unimplementable at the "C is not yet funded" stage.

Based on the posts above, I think I the option seller can rip off the buyer by mining a block that spends the 10 USDcoin. The 10 USDcoin needs to be escrowed somewhere.

Could we do the following? (sorry if I still don't understand multisig. If you can help clear up my misunderstandings that is progress for me at least)

A sells option to B

1) Create 2 of 2 multisig address using one of A's addresses and one of B's addresses. Call the multisig address C. Coins in address C can only be moved if both A and B sign (right?).
2) A signs 2 of 2 atomic txn moving 10 USDcoin from C->B and 1 BTC from B->A. Sends this info to B. B holds on to it for later signing and use. This will be his option, but C isn't funded yet.
3) B signs 2 of 2 atomic txn moving 10 USDcoin from C->A. Txn has nLockTime component and can only be put in block after block t. A holds on to it for later use. This is the option expiration, but C isn't funded yet.
4) A signs 2 of 2 atomic txn moving 10 USDcoin from A->C and 0.1 BTC from B->A. Sends to neutral third party. B signs 2 of 2 atomic txn moving 10 USDcoin from A->C and 0.1 BTC from B->A. Sends to neutral third party. Neutral third party broadcasts this txn if he promptly receives both sides of it and it enters a block. This txn pays A for the option and funds C.

Outcome:

1) The price of 1 BTC falls below 10USDcoin before block t. B exercises the option and trades his 1 BTC for A's 10USDcoin.
2) The price of 1 BTC does not fall below 10USDcoin before block t. At block t, A uses the option expiration and recovers his 10USDcoin. B's option becomes worthless because the address C isn't funded.

In terms of txn replacement, there needs to be some time-contingent txn priority. Before block t, (2) had to replace (3) in the memory pool. From block t and onwards, (3) has to replace (2) in the memory pool.

Once the locktime expires, all of the versions of the transaction become valid, and any of them can be mined.

The whole scheme needs a lot of thought.  Currently, I don't think that the stock client handles any transaction replacement at all, mostly because no one is sure how it should work.

That's the whole point of using proof-of-work, right?

A miner who wants to maximize fees paid in block he mines would include fee-paying transaction into a block even if it conflicts with non-final memory pool transaction.

Miner can always pretend that he haven't seen that non-final transaction, you can't know for sure that he violated thus rule intentionally.

So this rule appears pointless, it is neither strictly enforced nor economically motivated.

Blocks overrule the memorypool.

Yes. You are right.

One question though.

Can you mine a block that double spends inputs from txns in the memory pool. Is this block rejected by miners who saw the nLockTime txn first?

Yes, sorry, you're right. I meant options. If you replace the word future with options I think the rest of my post still stands.

I will respond to the rest tomorrow. For now...

Futures and options are not quite the same thing. It is very easy to get them confused.

With a future, parties A and B both have an obligation to exchange goods at the contracted price at a future date. Both parties are insuring each other and neither party exchanges money at the outset.

With an option, party A sells party B a right to exchange goods at the contracted price within a certain date range. Party B can choose whether to exercise the right or not. Party B has to pay Party A for the right upfront.

Say we are back in August, I want to speculate that colored pirate debt will collapse in value. I can buy an option to sell colored pirate debt at the current price 3 months in the future. First, I pay goat upfront for the option. Since I am just buying a right, I do not need to have the debt right now. Goat has an obligation, so he needs to have the necessary pirate debt locked away. If pirate debt has collapsed come October, I can buy the colored coins cheaply, and then sell them to goat at a profit. This is what I mean by "multisig for txns that are not currently valid, but may become valid." The option contract I am signing says that I will send coins I don't currently own.

Now compare this to a future. Trust-free futures are pretty useless as a shorting mechanism. With a future, I am committed to my side of the txn. It is an obligation, not a right. Thus, I need to get the pirate debt before I sign the txn. If I want to short pirate debt and I already own it, then I might as well sell it now. If I don't own it, I'm not going to buy it just so I can agree to sell it.

OK, futures in the chain would be cool.

Let's think. Why not just invert that arrangement? If I want to buy a future from you then I construct a transaction that sends 1 BTC from me to you and 10 USDcoin from you to me, then I send you that transaction to sign for the USDcoin input along with 0.1 BTC as the price of buying the contract. You give me back the signature I need.

Now you also construct a transaction that moves the 10 USDcoin output from your key back to your key again (it's a no-op) and set the sequence numbers to zero, nLockTime to the expiry time of the contract. It is broadcast and sits in the memory pool.

If the futures contract expires the second transaction commits and invalidates the first transaction, it becomes a double spend.

If I want to exercise my contract before the expiry time I just sign my input and broadcast it, and because it has higher sequence numbers (sequence numbers default to UINT_MAX) it replaces the no-op transaction and commits immediately.

There's an attack possible at the point where I send you 0.1 BTC to buy the contract and you send me back the signature. What if you don't do that? It could be fixed by making the 0.1 BTC payment an oracle mediated 2-of-3 transaction, as verifying you got a valid signature is trivial for a program.

Options. i.e. I sign one side of a 2 of 2 contract that allows you to sell 1 BTC at the rate of 1 BTC for 10 colored USD, this option expires at block X.
You purchase this and send me 0.1 BTC. I sign my end of the contract.

You now sit on the contract. If BTC drops below the price of 10 colored USD, you exercise the option and take profit. If BTC does not drop below the price of 10 colored USD, then you allow the option to expire. There needs to be an escrow mechanism preventing either party from moving their coins except through this txn, until block X arrives.

I'm pretty sure zero-trust options qualify as useful stuff. Right now you can issue options, but you have to trust option issuer. In this case, you don't have to trust anyone. In fact if you distrust the guy who issued the colored coins, then you can make money via options trading in his junk debt. This is good. If there had been a zero-trust market for options to sell pirate's junk debt, you could have shorted pirate without having to trust anyone. This is good.


Yes, this is a problem. You could actually commit to rewarding attackers ahead of time. That is not good. You can currently reward side chains ex-post, by sending coins to whoever mines them. However, ahead of time you can only promise, you cannot commit. You would have to establish reputation for making payments before you could pull this off. I don't think contacting the miners is currently a big issue, just include a message with attack instructions in the blockchain.

Simple fix is just to not allow txn fees to accompany this type of txn.  More complicated fix is to put caps on the fee you can use AND caps on the number of this type of txn per block.

Of course, it is a hard fork. I think hard forks should be introduced much more aggressively. I understand that the prevailing attitude is 'avoid at all costs'.
I think that if you just disallow txn fees for this txn type, then this hard fork would be innocuous.

I see, sorry, I misunderstood. So not actually affecting transaction validity, but just whether it's allowed to be included or not.

I think it would be possible but I'd be against it for several reasons:

1. It's obviously a hard-forking rule change and those are fraught with unexpected side effects, not to mention requiring a global upgrade. It's not like nLockTime which is already understood by every node, or replacement which only affects the memory pools. The effort involved in adding such a feature is huge.

3. It'd give an easy way to anonymously incentivize mining on side chains, whereas today there is none. If I want to double spend a confirmed transaction then I can mine a block at height head-2 and broadcast an all-fee tx that is only valid until the current chain height (not includable on the current best chain). To claim the fee miners will be incentivized to switch to mining on the side chain. Once a block is found on the side chain I can continue to incentivize mining on that fork by creating another "valid until next block" tx that spends my double-spending tx, again with some fees. To claim all the fees then, miners have to try and extend my side chain. Whilst it's possible to set up such an arrangement today, you'd have to find and contact all kinds of miners independently and that's a ton of effort, not to mention you'd probably get detected and caught. If you can do it just by broadcasting a few transactions the difficulty gets a lot lower.

4. I am unconvinced it's useful or necessary. Your example doesn't seem that compelling. In practice people execute trades with each other in the face of moving prices all the time. If you want to abort the trade before it executes, go ahead. Somebody else will take it at the new price.

By valid before time T, I mean miners can be include the txn in any mined block before block #T, but not in blocks after block #T.

Could you explain how this would cause block chain splits?

The new transaction must still be valid. Whether the signatures in the existing inputs are still valid or not depends on their SIGHASH flags. The default SIGHASH_ALL does not allow replacement unless all parties agree to the new version. The other modes allow individual participants to replace transactions by setting the sequence number in their input to a higher value whilst leaving the sequence numbers in the other inputs alone.


No. You can't make a transaction that's valid before time T but not after. It would result in block chain splits.

C is the broker then. Perhaps people could just download brokerage clients on their computers, they could share information about bids and asks via a P2P network.
The broker could be selected through a random process among the network. Brokers who fail to respond quickly after they receive information could be blacklisted.

There could be some nominal brokerage fee to incentivize participation, i.e. just enter your bitcoin address into the P2P client.

 

I'm not sure whether "transaction update" mechanism can help us in this case, it looks like things which can be updated won't allow one to re-target funds. But maybe I'm missing something...

Anyway, this problem can be solved with a help of a not-very-trusted third party: instead of sending his signature to B, A will send it to a third party C. B will do the same.

C will broadcast complete transaction only when he has both signatures and renegotiation time has expired.

C only needs to be trusted to not favor one of parties.

Suppose you re-enable tx replacement. Can you unilaterally replace these txns, or do you need agreement from all signatories?

I think the tx'ing parties should be able to specify whether unilateral replacement is allowed or not in the original txn.

When you re-enable this, can you also make a mirror image of nLockTime for txns in block t or earlier, rather than just t or later?  This would seem useful for options trading.

Other purposes too such as I described above.