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

---

