<p>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.</p>

<p>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.</p>

<p>To solve the problem, you need to use such an address that Alice's signature is <em>required</em> 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 <a href="https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit" rel="nofollow">here</a>.</p>

CC BY-SA 3.0
2014-10-01T06:08:57.163Z
2014-10-01T06:08:57.163Z
abacabadabacaba
<p>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.</p>

<p>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.</p>

<p>Alice trusting her bank not to double spend, she can let Bob leave.</p>

<p>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.</p>

CC BY-SA 3.0
2015-03-30T14:27:05.497Z
2015-03-30T14:27:05.497Z
Nicolas Dorier
<p>A solution to use in this case is a <a href="https://bitcoinj.github.io/working-with-micropayments" rel="nofollow">micropayment channel</a>. 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.</p>

CC BY-SA 3.0
2015-03-30T10:33:05.230Z
2015-03-30T10:33:05.230Z
Meni Rosenfeld
<p>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.</p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2014-04-10T11:43:28.177Z
When you have a transaction as large as a car, waiting around 10 minutes for a confirmation is a small price to pay.
Tim S.
CC BY-SA 3.0
2014-05-17T06:44:25.267Z
"So instead Alice creates a multisig address"
so Alice has the three private key ? I think they have to wait more then +1 confirmations.
JohnsonDiao
CC BY-SA 3.0
2014-05-17T11:31:38.073Z
You should use a combination of comments on your own question and edits of your question (for longer additions) rather than adding a non-answer.
dchapes
<multi-signature>
Can a 2 of 3 multisig transaction signature be revoked before it gets confirmed by the miners?
Ember
# Can a 2 of 3 multisig transaction signature be revoked before it gets confirmed by the miners?

(Asked by: username_0 on 2014-04-10)

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?

**Tags:** multi-signature

> **Comments:**
> **username_1**: When you have a transaction as large as a car, waiting around 10 minutes for a confirmation is a small price to pay.  
> **username_2**: "So instead Alice creates a multisig address" so Alice has the three private key ? I think they have to wait more then +1 confirmations.  
> **username_3**: You should use a combination of comments on your own question and edits of your question (for longer additions) rather than adding a non-answer.  

---

## 3 answers

### Answer by username_4 on 2014-10-01. Score: 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](https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit).


---

### Answer by username_5 on 2015-03-30. Score: 0

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.

username_6 username_6'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.


---

### Answer by username_6 on 2015-03-30. Score: 0

A solution to use in this case is a [micropayment channel](https://bitcoinj.github.io/working-with-micropayments). 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.


---

