2
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.
3
There is something like this described on the wiki.
Update: As Meni 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.
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 – 2012-04-07T08:51:08.700
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 – 2012-04-08T09:08:21.037
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 – 2012-04-08T17:00:21.170
@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 – 2012-04-08T18:43:10.707