<p>Your protocol makes sense, but i would modify it as follows</p>

<ol>
<li>the 1btc sent to trent should also be mutlisig with Alice's signature as the 2nd one, so that if Trent fails to do what he promised he gets no commission. ((the 1btc will stay in limbo, unless Alice and Trent can somehow work this out)</li>
<li>The Tx2 should also be multisig and Carol's signature should be added, that way Trent can't run with the money.</li>
</ol>

CC BY-SA 3.0
2016-09-20T00:56:50.947Z
2016-09-20T00:56:50.947Z
Albert S
<p>There is BTCrow (<a href="http://btcrow.com/" rel="nofollow">http://btcrow.com/</a>) and ThruCoin (<a href="http://thrucoin.com/create" rel="nofollow">http://thrucoin.com/create</a>), which both look like they will perform the services you need.</p>

CC BY-SA 3.0
2013-03-18T15:21:28.310Z
Thanks @cjastram, but I'm not looking for a service that implements it but for a description of the best information flow between parties. Also note that Carol is an uninvolved 3rd party, if that makes any difference.
nivs
CC BY-SA 3.0
2013-03-18T14:33:37.753Z
2013-03-18T14:33:37.753Z
cjastram
<p><strong>Alice</strong> wants <strong>Bob</strong> to transfer 10btc to <strong>Carol</strong>, and is willing to pay <strong>Bob</strong> 11btc for the transfer.</p>

<p>They both entrust <strong>Trent</strong> to mediate the transaction, and <strong>Alice</strong> is willing to pay <strong>Trent</strong> 1btc as commission.</p>

<p>What is the correct and most secure protocol for performing this contract?</p>

<hr>

<p><strong>Edit</strong>: does the following protocol make sense?</p>

<ol>
<li><strong>Alice</strong> broadcasts a transaction (<em>Tx1</em>) with 2 outputs:
<ul>
<li>11btc with an output script specifying 2-of-3 multi-signature verification, specifying <strong>Alice</strong>, <strong>Bob</strong> and <strong>Trent</strong> as recipients</li>
<li>1btc to <strong>Trent</strong> (commission)</li>
</ul></li>
<li><strong>Bob</strong> verifies <strong>Alice</strong>'s transaction:
<ul>
<li><em>Verified:</em> <strong>Bob</strong> broadcasts a transaction (<em>Tx2</em>) sending <strong>Trent</strong> 10btc</li>
<li><em>Rollback</em> - <strong>Bob</strong> is unsatisfied or fails to transfer the funds to <strong>Trent</strong>: <strong>Trent</strong> broadcasts a transaction (<em>Tx3</em>) sending <strong>Alice</strong> her 11btc back, specifying <em>Tx1</em>'s first output as an input and signs the input. When <strong>Alice</strong> wants to spend <em>Tx3</em>, adding her signature to the input satisfies the 2-of-3 requirement (and the process stops here)</li>
</ul></li>
<li><strong>Trent</strong> broadcasts a transaction (<em>Tx4</em>) sending <strong>Bob</strong> the 11btc, specifying <em>Tx1</em>'s first output as an input. When <strong>Bob</strong> wants to spend <em>Tx4</em>, adding his signature to the input satisfies the 2-of-3 requirement</li>
<li><strong>Trent</strong> broadcasts a transaction (<em>Tx5</em>) sending <strong>Carol</strong> 10btc, specifying <em>Tx2</em> as an input</li>
</ol>

CC BY-SA 3.0
2013-03-18T15:18:06.807Z
Why doesn't Alice pay Carol 10 BTC herself, then pay 1 BTC to Bob?
Nick ODell
CC BY-SA 3.0
2013-03-18T15:32:58.290Z
Theoretically, Alice wants plausible deniability regarding the transfer of funds to Carol.
nivs
CC BY-SA 3.0
2013-03-18T18:22:13.027Z
The Bitcoin protocol can do M of N transactions, but the clients don't yet support it.  The solution will be coming.
Stephen Gornick
CC BY-SA 3.0
2013-03-18T19:16:02.327Z
Thanks Stephen. What I'm looking for is the best security protocol for fulfilling the contract (preserving the plausible deniability of Alice, making sure Alice and Bob transfer funds, and enabling Trent to rollback the transaction), regardless of client implementation.
nivs
CC BY-SA 3.0
2014-01-13T04:05:11.167Z
For clarification, as far as "plausible deniability", it should appear that the final decision to transfer funds to Carol was made by Bob and/or Trent, not Alice?
Nate Eldredge
CC BY-SA 3.0
2014-01-13T04:08:46.070Z
Also, is Bob supposed to front his own 10btc to Carol and then be reimbursed, or does it have to come out of the coins he gets from Alice?
Nate Eldredge
<transactions><trust><multi-signature>
Mediated transfer of funds between three parties
nivs
# Mediated transfer of funds between three parties

(Asked by: username_0 on 2013-03-18)

**Alice** wants **Bob** to transfer 10btc to **Carol**, and is willing to pay **Bob** 11btc for the transfer.

They both entrust **Trent** to mediate the transaction, and **Alice** is willing to pay **Trent** 1btc as commission.

What is the correct and most secure protocol for performing this contract?

---

**Edit**: does the following protocol make sense?

1. **Alice** broadcasts a transaction (*Tx1*) with 2 outputs:
   * 11btc with an output script specifying 2-of-3 multi-signature verification, specifying **Alice**, **Bob** and **Trent** as recipients
   * 1btc to **Trent** (commission)
2. **Bob** verifies **Alice**'s transaction:
   * *Verified:* **Bob** broadcasts a transaction (*Tx2*) sending **Trent** 10btc
   * *Rollback* - **Bob** is unsatisfied or fails to transfer the funds to **Trent**: **Trent** broadcasts a transaction (*Tx3*) sending **Alice** her 11btc back, specifying *Tx1*'s first output as an input and signs the input. When **Alice** wants to spend *Tx3*, adding her signature to the input satisfies the 2-of-3 requirement (and the process stops here)
3. **Trent** broadcasts a transaction (*Tx4*) sending **Bob** the 11btc, specifying *Tx1*'s first output as an input. When **Bob** wants to spend *Tx4*, adding his signature to the input satisfies the 2-of-3 requirement
4. **Trent** broadcasts a transaction (*Tx5*) sending **Carol** 10btc, specifying *Tx2* as an input

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

> **Comments:**
> **username_1**: Why doesn't Alice pay Carol 10 BTC herself, then pay 1 BTC to Bob?  
> **username_0**: Theoretically, Alice wants plausible deniability regarding the transfer of funds to Carol.  
> **username_2**: The Bitcoin protocol can do M of N transactions, but the clients don't yet support it.  The solution will be coming.  
> **username_0**: Thanks username_2. What I'm looking for is the best security protocol for fulfilling the contract (preserving the plausible deniability of Alice, making sure Alice and Bob transfer funds, and enabling Trent to rollback the transaction), regardless of client implementation.  
> **username_3**: For clarification, as far as "plausible deniability", it should appear that the final decision to transfer funds to Carol was made by Bob and/or Trent, not Alice?  
> **username_3**: Also, is Bob supposed to front his own 10btc to Carol and then be reimbursed, or does it have to come out of the coins he gets from Alice?  

---

## 2 answers

### Answer by username_4 on 2016-09-20. Score: 1

Your protocol makes sense, but i would modify it as follows

1. the 1btc sent to trent should also be mutlisig with Alice's signature as the 2nd one, so that if Trent fails to do what he promised he gets no commission. ((the 1btc will stay in limbo, unless Alice and Trent can somehow work this out)
2. The Tx2 should also be multisig and Carol's signature should be added, that way Trent can't run with the money.


---

### Answer by username_5 on 2013-03-18. Score: -1

There is BTCrow (<http://btcrow.com/>) and ThruCoin (<http://thrucoin.com/create>), which both look like they will perform the services you need.

> **Comments:**
> **username_0**: Thanks @username_5, but I'm not looking for a service that implements it but for a description of the best information flow between parties. Also note that Carol is an uninvolved 3rd party, if that makes any difference.  

---

