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

[cunicula]

[tl;dr simple financial trading doesn't work well via simple multisig/"atomic coin swapping". I describe a theoretical fix for that. Not sure if it can implemented. What do you think?]

In financial trading, there is a problem with regret. Prices move, making one party happy and the other party sad. Standard multisig requires that one person move first. The second person has no obligation to sign his end of a partially-signed txn. This allows the second person to back out of all non-profitable txns. Rationally, no-one should offer to go first. Alternatively, the person needs compensation to motivate them. (essentially they are selling an option to the person going second, not just making a regular trade)

Could we allow both parties to back out of trades up to a certain time frame. If so, then only mutually agreeable trades would be concluded.

Specifically, is the following arrangement possible? (I'm going to go start with the second broadcast txn, and then work backwards to a pair of initially broadcast txns.)

A and B want to do the following multisig txn in block t. At time t-1, they sign the following txn. (It doesn't matter who signs first here. A and B are indifferent about that.)

1 BTC from A to B
10 coloredUSD from B to A
This is valid in only blocks t or earlier. Outputs in this txn may not be spent until block t+2, except in the case below.

They also want to have an opportunity to reverse this txn up to time t+1. At time t-2, before they produce the real txn, they sign half of the following "anti-txn".  (Again, it doesn't matter who signs first here. A and B are indifferent about that.)

10 coloredUSD from A to B
1 BTC from B to A
This is valid in only blocks t+1 or earlier.

There are two versions of this txn, so either party can back out at any time before t+1.

The "anti-txn" would only be valid if it is submitted after the actual txn enters a block.

[sorry if this has been covered before, it is difficult to keep track of everything. To sum up the gist of this, if BTC prices are stable, then txn will go through. If BTC prices fluctuate between t-1 and t+1, then the txn will be reversed and prices will need to be renegotiated in a new txn. We keep renegotiating until a mutually agreeable trade can be completed. Txn fees prevent us from renegotiating over trivial issues.]

[killerstorm]

There is no "valid until" feature in transaction, but there is "not valid till" feature. It is called nLockTime: before nLockTime happens, transaction isn't considered final (locked) and thus cannot go into block. nLockTime can be specified either in wallclock time, or it can be specified as block number.

As you can see, this feature is frequently used to implement contracts: https://en.bitcoin.it/wiki/Contracts

You can simply use nLockTime somewhere in future and no party will haven an advantage in multisig/coin swap transaction: both can back out before nLockTime by spending their output.

It is less than perfect because it is prone to all sorts of race conditions, it is just that no party has a priority in that race.

[cunicula]

Based on this post, nLockTime won't really do much at all.
https://bitcointalk.org/index.php?topic=115084.msg1274478#msg1274478
Once the txn is broadcast neither party can spend coins out from under it regardless of whether nLocktime is enabled or not.

Is there a plan to change this so that you can generically "spend coins out from under" an nLockTime txn, unilaterally invalidating it. This seems like a good idea to me.

Otherwise, I can't understand what the point of nLocktime is.

[Mike Hearn]

nLockTime was designed to operate in conjunction with sequence numbers, which let you replace timelocked transactions that were already broadcast (a better phrase might be "update").

A long time ago tx replacement was disabled after a series of bugs were found in the Bitcoin code, and there was a desire to reduce the programs surface area by disabling unused features. So we need to re-activate it at some point after building confidence that it's safe.

[cunicula]

nLockTime was designed to operate in conjunction with sequence numbers, which let you replace timelocked transactions that were already broadcast (a better phrase might be "update").

A long time ago tx replacement was disabled after a series of bugs were found in the Bitcoin code, and there was a desire to reduce the programs surface area by disabling unused features. So we need to re-activate it at some point after building confidence that it's safe.

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.

[killerstorm]

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.

[cunicula]

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.

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.

 

[Mike Hearn]

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

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.

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.

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

[cunicula]

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

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?

[Mike Hearn]

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.

[cunicula]

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.

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.

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.

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.

[Mike Hearn]

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.

[cunicula]

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.

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.

[Mike Hearn]

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.

[cunicula]

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?

[kjj]

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?

Blocks overrule the memorypool.

[killerstorm]

Blocks overrule the memorypool.

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.

[kjj]

Blocks overrule the memorypool.

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.

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.

[cunicula]

If I want to buy a option 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.

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.

[Mike Hearn]

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.