<p>This scenario appears a bit constructed to me.</p>

<p><strong>1. Escrow:</strong><br>
Shortterm escrow services are usually used to mediate a payment between two parties, providing a tie-breaker to make sure the payee fulfills the paid service, and payer pays services rendered. I don't see what need someone might have that requires relinquishing control of his money to a third party just to withdraw within minutes. Hence, it seems contra intuitive that an "escrow" service would exist that facilitates deposits and withdrawals of a payment at such a frequency. A similar situation might be constructed with an exchange, though. They don't usually guarantee payout times as far as I know, though.</p>

<p><strong>2. Confirmations:</strong><br>
If the payee is waiting for at least one confirmation, the payer must be under the influence of a Sybil attack and fed false blockchain data, or the attacker must create an alternative blockchain tip that orphans the block the payee relies on for the confirmation. Either way, the attacker must create at least one block before the withdrawal which would constitute quite an investment.</p>

<p><strong>3. Attack is easily countered:</strong><br>
In the situation that a client wants to withdraw back immediately, the "escrow" would create a transaction using the transaction output of the deposit transaction as input. That way, the client would get their money back reliably if it was paid, or the withdrawal would fail, if their money never arrived in the escrow's wallet.</p>

<p><strong>How many confirmations to wait?</strong><br>
If I were offering an "escrow" service, I'd be implementing it via 2 of 3 multisig addresses. The three keys would belong to Payer, Payee, and Escrow. As the address would be unique to the involved parties, payments would be sourced from the deposit anyhow. </p>

<p>Depending on the amounts involved and the quality of my business relationship with the involved parties, I'd wait at least between one and four confirmations before I'd pronounce the payment as received.</p>

CC BY-SA 3.0
2016-04-28T16:17:08.817Z
2016-04-30T07:01:07.717Z
2016-04-30T07:01:07.717Z
Murch
<p>To me it seems very dangerous not to wait for 6 confirmations when running an escrow.</p>

<p>The scenario I'm thinking of:</p>

<ol>
<li>a miner deposits a large sum of bitcoins </li>
<li>the escrow waits for one or two confirmations</li>
<li>the miner performs one of the three double spend attacks successfully</li>
<li>the miner withdraws his bitcoins from the escrow service</li>
</ol>

<p>Where do those bitcoins come from?<br>
Those bitcoins are then obviously taken from another user.<br>
All assuming the escrow stores all users' bitcoins in one wallet.</p>

<p>so back to my original question:<br> 
How many confirmations should an escrow wait for? And why?</p>

CC BY-SA 3.0
2016-04-27T14:09:28.963Z
Seems like the same question as here: http://bitcoin.stackexchange.com/questions/8360/how-many-confirmations-do-i-need-to-ensure-a-transaction-is-successful?rq=1
datashaman
CC BY-SA 3.0
2016-04-28T15:56:13.107Z
Could you please enlighten us, which three doublespend attack types you are referring to that work after a transaction has been confirmed?
Murch
CC BY-SA 3.0
2016-04-28T16:57:20.720Z
Well the three I was referring to are: The 51% attack, finney attack and the Race attack.
Fastboy619
CC BY-SA 3.0
2016-04-29T06:19:36.447Z
Finney attack and Race attack don't work after a payment has a confirmation.
Murch
<security><confirmations><doublespend><escrow><fraud>
How many confirmations do bitcoin escrow websites wait on average?
Fastboy619
# How many confirmations do bitcoin escrow websites wait on average?

(Asked by: username_0 on 2016-04-26)

To me it seems very dangerous not to wait for 6 confirmations when running an escrow.

The scenario I'm thinking of:

1. a miner deposits a large sum of bitcoins
2. the escrow waits for one or two confirmations
3. the miner performs one of the three double spend attacks successfully
4. the miner withdraws his bitcoins from the escrow service

Where do those bitcoins come from?  
Those bitcoins are then obviously taken from another user.  
All assuming the escrow stores all users' bitcoins in one wallet.

so back to my original question:  
How many confirmations should an escrow wait for? And why?

**Tags:** security, confirmations, doublespend, escrow, fraud

> **Comments:**
> **username_1**: Seems like the same question as here: http://bitcoin.stackexchange.com/questions/8360/how-many-confirmations-do-i-need-to-ensure-a-transaction-is-successful?rq=1  
> **username_2**: Could you please enlighten us, which three doublespend attack types you are referring to that work after a transaction has been confirmed?  
> **username_0**: Well the three I was referring to are: The 51% attack, finney attack and the Race attack.  
> **username_2**: Finney attack and Race attack don't work after a payment has a confirmation.  

---

## 1 answers

### Answer by username_2 on 2016-04-28. Score: 0 | Accepted answer

This scenario appears a bit constructed to me.

**1. Escrow:**  
Shortterm escrow services are usually used to mediate a payment between two parties, providing a tie-breaker to make sure the payee fulfills the paid service, and payer pays services rendered. I don't see what need someone might have that requires relinquishing control of his money to a third party just to withdraw within minutes. Hence, it seems contra intuitive that an "escrow" service would exist that facilitates deposits and withdrawals of a payment at such a frequency. A similar situation might be constructed with an exchange, though. They don't usually guarantee payout times as far as I know, though.

**2. Confirmations:**  
If the payee is waiting for at least one confirmation, the payer must be under the influence of a Sybil attack and fed false blockchain data, or the attacker must create an alternative blockchain tip that orphans the block the payee relies on for the confirmation. Either way, the attacker must create at least one block before the withdrawal which would constitute quite an investment.

**3. Attack is easily countered:**  
In the situation that a client wants to withdraw back immediately, the "escrow" would create a transaction using the transaction output of the deposit transaction as input. That way, the client would get their money back reliably if it was paid, or the withdrawal would fail, if their money never arrived in the escrow's wallet.

**How many confirmations to wait?**  
If I were offering an "escrow" service, I'd be implementing it via 2 of 3 multisig addresses. The three keys would belong to Payer, Payee, and Escrow. As the address would be unique to the involved parties, payments would be sourced from the deposit anyhow.

Depending on the amounts involved and the quality of my business relationship with the involved parties, I'd wait at least between one and four confirmations before I'd pronounce the payment as received.


---

