<p>There is <a href="https://en.bitcoin.it/wiki/Contracts#Example_3%3a_Assurance_contracts" rel="nofollow">something like this described on the wiki</a>.</p>

<p><strong>Update</strong>: As Meni wrote in a comment below, this is more flexible than you require, since you already know who should pay, and how much.</p>

<p>So we can create a single transaction with 2 inputs, one from Alice and one from Bob, and a single output to the recipient of the payment.</p>

<p>Alice and Bob need to both have an input in their wallet of the right size, so we don't worry about who gets the change.  Then Alice tells Bob what input she's going to use.  Bob makes a transaction including both Alice's and Bob's input, and signs his input with SIGHASH_ALL, meaning that his signature isn't valid unless Alice also signs her input.  He then sends the incomplete transaction to Alice for her to sign, she signs her input, and sends the result to the network.</p>

CC BY-SA 3.0
2012-04-07T08:51:08.700Z
The assurance contract seemed like it solved the problem I was asking. But I know almost nothing about cryptography and so although I read the wiki page I could not understand most of it.
user782220
CC BY-SA 3.0
2012-04-08T09:08:21.037Z
Assurance contracts are overkill for the OP's purpose (designed for cases we don't know in advance who are the senders). What the OP is looking for is a simple transaction which has inputs from both Alice and Bob, requiring both to sign the transaction in order to carry it through.
Meni Rosenfeld
CC BY-SA 3.0
2012-04-08T17:00:21.170Z
Thanks Meni.  Is my updated answer how you see it working?  I notice that the assurance contract is vulnerable to an attack by the recipient.  If he doesn't get enough contributions to release the funds, he can simply add payments to himself to the transaction, and get the funds that way.
Chris Moore
CC BY-SA 3.0
2012-04-08T18:43:10.707Z
@ChrisMoore: Yes, though there's no need to have the exact amount; there can simply be a change output for Alice and a change output for Bob. I guess whether what you describe with the assurance contract is a vulnerability depends on the use case; usually the recipient will have some obligation if he receives the payment, so he has no incentive to fake it.
Meni Rosenfeld
CC BY-SA 3.0
2012-04-07T07:48:01.867Z
2012-04-08T17:03:34.600Z
2012-04-08T17:03:34.600Z
Chris Moore
<p>Is it possible to have a kind of "multiparty" transaction in bitcoin. For example, a protocol where say Alice and Bob send you bitcoins at the same time, but if Bob tries to break the protocol and not send bitcoins Alice will not end up sending bitcoins either.</p>

<p>Something the ensures that both send or both don't send.</p>

<transactions>
Multiparty transaction
user782220
# Multiparty transaction

(Asked by: username_0 on 2012-04-07)

Is it possible to have a kind of "multiparty" transaction in bitcoin. For example, a protocol where say Alice and Bob send you bitcoins at the same time, but if Bob tries to break the protocol and not send bitcoins Alice will not end up sending bitcoins either.

Something the ensures that both send or both don't send.

**Tags:** transactions


---

## 1 answers

### Answer by username_1 on 2012-04-07. Score: 3

There is [something like this described on the wiki](https://en.bitcoin.it/wiki/Contracts#Example_3%3a_Assurance_contracts).

**Update**: As username_2 wrote in a comment below, this is more flexible than you require, since you already know who should pay, and how much.

So we can create a single transaction with 2 inputs, one from Alice and one from Bob, and a single output to the recipient of the payment.

Alice and Bob need to both have an input in their wallet of the right size, so we don't worry about who gets the change. Then Alice tells Bob what input she's going to use. Bob makes a transaction including both Alice's and Bob's input, and signs his input with SIGHASH\_ALL, meaning that his signature isn't valid unless Alice also signs her input. He then sends the incomplete transaction to Alice for her to sign, she signs her input, and sends the result to the network.

> **Comments:**
> **username_0**: The assurance contract seemed like it solved the problem I was asking. But I know almost nothing about cryptography and so although I read the wiki page I could not understand most of it.  
> **username_2**: Assurance contracts are overkill for the OP's purpose (designed for cases we don't know in advance who are the senders). What the OP is looking for is a simple transaction which has inputs from both Alice and Bob, requiring both to sign the transaction in order to carry it through.  
> **username_1**: Thanks username_2.  Is my updated answer how you see it working?  I notice that the assurance contract is vulnerable to an attack by the recipient.  If he doesn't get enough contributions to release the funds, he can simply add payments to himself to the transaction, and get the funds that way.  
> **username_2**: @username_1: Yes, though there's no need to have the exact amount; there can simply be a change output for Alice and a change output for Bob. I guess whether what you describe with the assurance contract is a vulnerability depends on the use case; usually the recipient will have some obligation if he receives the payment, so he has no incentive to fake it.  

---

