<p>Yes. There's a project called Lighthouse that does something very similar. Bitcoin transactions either completely succeed or completely fail. We can use this by starting with a transaction that has the outputs we want. </p>

<pre><code>--&gt; TX -- 0.5 BTC --&gt; Charlie
</code></pre>

<p>This is invalid, because it doesn't have any inputs.</p>

<p>We add Alice's input.</p>

<pre><code>Alice --&gt; 0.25 BTC --+
                     +--&gt; TX -- 0.5 BTC --&gt; Charlie
</code></pre>

<p>This is invalid, because the transaction creates more in outputs than it takes in inputs. It can't be partially spent, either. It's all or nothing.</p>

<p>We add Bob's input.</p>

<pre><code>Alice --&gt; 0.25 BTC --+
                     +--&gt; TX -- 0.5 BTC --&gt; Charlie
Bob   --&gt; 0.25 BTC --+
</code></pre>

<p>Now the transaction is valid, and can be pushed to the Bitcoin blockchain. Modifying it will require Alice and Bob to re-sign it. If we want Bob to have some Bitcoins at the end, the procedure is the same, except we start with outputs that pay both Charlie and Bob.</p>

CC BY-SA 3.0
2017-05-05T06:54:18.597Z
not sure I got it, what would be the difference to a multisig spend? Is the difference the reverse order? I don't need a redeem script with lighthouse?
pebwindkraft
CC BY-SA 3.0
2017-05-05T12:31:17.400Z
Thanks! While I am still fuzzy on the details, it's certainly a better starting point :)
UriCS
CC BY-SA 3.0
2017-05-05T17:25:26.860Z
@pebwindkraft A multisig output only allows a spend if enough signatures agree. In the example above, Alice could defect and send her money to David before Bob signs the transaction. However, this would cause the combined Alice-Bob transaction to fail, so the property the OP asked for still holds.
Nick ODell
CC BY-SA 3.0
2017-05-05T04:35:07.593Z
2017-05-05T04:35:07.593Z
Nick ODell
<p>I am familiar with Bitcoin's model, but a complete noob in real-world details. I am entertaining the idea of a service that receives transactions (A->B) and "wraps" or completes them to include (A->B &amp; B->C).</p>

<p>Is it possible to create a transaction requiring 2 wallets to participate?<br>
For example, to create a transaction sending coins from Alice to Bob, and from Bob to Charlie?<br>
I had in mind a process where Alice creates the first half-baked transaction (Alice -> Bob), send it to Bob, Bob "adds" its piece (Bob -> Charlie), and the result is a valid transaction.<br>
Obviously, the (Alice -> Bob) part must not be reusable by anyone else.</p>

<p>Can that be achieved? How? What's a good starting point / alternatives?</p>

<transactions><multi-signature><mixing>
Can a transaction be created by 2 different wallets?
UriCS
# Can a transaction be created by 2 different wallets?

(Asked by: username_0 on 2017-05-05)

I am familiar with Bitcoin's model, but a complete noob in real-world details. I am entertaining the idea of a service that receives transactions (A->B) and "wraps" or completes them to include (A->B & B->C).

Is it possible to create a transaction requiring 2 wallets to participate?  
For example, to create a transaction sending coins from Alice to Bob, and from Bob to Charlie?  
I had in mind a process where Alice creates the first half-baked transaction (Alice -> Bob), send it to Bob, Bob "adds" its piece (Bob -> Charlie), and the result is a valid transaction.  
Obviously, the (Alice -> Bob) part must not be reusable by anyone else.

Can that be achieved? How? What's a good starting point / alternatives?

**Tags:** transactions, multi-signature, mixing


---

## 1 answers

### Answer by username_1 on 2017-05-05. Score: 1 | Accepted answer

Yes. There's a project called Lighthouse that does something very similar. Bitcoin transactions either completely succeed or completely fail. We can use this by starting with a transaction that has the outputs we want. 
--> TX -- 0.5 BTC --> Charlie

This is invalid, because it doesn't have any inputs.
We add Alice's input.
Alice --> 0.25 BTC --+
                     +--> TX -- 0.5 BTC --> Charlie

This is invalid, because the transaction creates more in outputs than it takes in inputs. It can't be partially spent, either. It's all or nothing.
We add Bob's input.
Alice --> 0.25 BTC --+
                     +--> TX -- 0.5 BTC --> Charlie
Bob   --> 0.25 BTC --+

Now the transaction is valid, and can be pushed to the Bitcoin blockchain. Modifying it will require Alice and Bob to re-sign it. If we want Bob to have some Bitcoins at the end, the procedure is the same, except we start with outputs that pay both Charlie and Bob.

> **Comments:**
> **username_2**: not sure I got it, what would be the difference to a multisig spend? Is the difference the reverse order? I don't need a redeem script with lighthouse?  
> **username_0**: Thanks! While I am still fuzzy on the details, it's certainly a better starting point :)  
> **username_1**: @username_2 A multisig output only allows a spend if enough signatures agree. In the example above, Alice could defect and send her money to David before Bob signs the transaction. However, this would cause the combined Alice-Bob transaction to fail, so the property the OP asked for still holds.  

---

