Can a 2 of 3 multisig transaction signature be revoked before it gets confirmed by the miners?

Question

The reason I'm asking is because I want to know if 2-of-3 can be used by two parties as a way for one party to pre-commit to purchasing something before they actually do. For example, suppose Alice is selling her old car for 2 BTC, and Bob has said over the phone that he'd like to buy it. When Bob shows up and pays, naturally Alice wants to wait for at least 1 confirmation just to make sure Bob's not pulling a fast one on her and trying to double-spend the coins back to himself.

It's inconvenient to have Bob wait around for 10 minutes (and possibly an hour or more if mining luck is really low, or if Alice wants more than 1 confirm). So instead Alice creates a multisig address that Bob sends money to, and the transaction to the multisig addresses gets 1+ confirmations before he shows up, then Alice signs it. Once Bob arrives to inspect the car, possibly changing his mind but otherwise deciding to go through with it, he broadcasts his signature and drives away.

Does Alice need to wait for 1+ confirmations of Bob's signature to be sure she'll get the funds before letting him leave? She may want to verify that blockchain.info sees the transaction just to make sure it has been broadcast (as Bob's phone or whatever might be conveniently offline when he 'broadcasts' his signature), but having done that, is there any danger left?

Answer 1

The problem is that you can't broadcast just a signature. You can only broadcast a complete transaction with enough signatures to make it valid. Likewise, there is no way to revoke a signature. The only way to "cancel" a transaction is to broadcast another transaction which spends the same input as the original transaction. After that, there is a chance that the new transaction will be confirmed instead of the old one.

There is no point in having 2-of-3 address if there is one person who has 2 keys. That person can spend any money from such address, and the person who has the third key can't spend anything without the other person's assistance. In your scenario, Bob can double-spend his payment before it is confirmed by using both of his keys.

To solve the problem, you need to use such an address that Alice's signature is required to spend from it. For example, 2-of-2 address will work. To make sure that Bob can have his money back if the deal doesn't go through, you can use the approach described here.

Answer 2

A solution to use in this case is a micropayment channel. Before they meet, Bob sets up a micropayment channel to Alice, locking the price of the car. The channel will be confirmed by the time they meet. When they meet, if everything is ok Bob uses the channel to pay Alice instantly. If not, the locked funds will eventually be sent back to Bob.

Answer 3

In such a scenario, the best way to deal with it actually is to use an trusted third party escrow. We can imagine banks or popular car sellers providing such services in the future.

Bob would sends money to a 2-2 owned by bank+alice. If Bob is happy with it, he informs the bank directly and the bank and alice signs.

Alice trusting her bank not to double spend, she can let Bob leave.

Meni Rosenfeld's micropayment solution is not recommended currently, because of malleability issues the "refunding transaction" can be rendered ineffective, which would block the funds. But this will be the best solution once OP_CHECKLOCKTIMEVERIFY is enforced by miners because no trusted parties will be involved. V3 transactions would also solve the problem.