<p>There's a significant increase in the risk of being defrauded when the merchant accepts payment 0/unconfirmed and at the same time has bitcoind configured for incoming transactions.  In that situation, the attacker can reach a near 100% success in double spending against the merchant simply by making a direct connection to that merchant's node and broadcasting one transaction to it and then to the rest of the network broadcasting a double spend transaction.</p>

<p>But when the merchant waits until there is at least one confirmation the this race attack risk essentially disappears.</p>

<p>To disable listening, the setting is "listen=0".</p>

CC BY-SA 3.0
2013-09-19T11:58:08.650Z
I really liked your answer but I can only accept one. Sorry.
Konstantin Schubert
CC BY-SA 3.0
2013-09-19T09:28:13.977Z
2013-09-19T09:28:13.977Z
Stephen Gornick
<p>At the moment there's very little orphaning of blocks, and next to no occurrence of two-block side chains. Unless you're dealing with large amounts (larger than two block rewards worth, probably), your chances of attack are incredibly incredibly low. If you're dealing with amounts less than a few BTC, I'd personally be happy accepting one-confirmation transactions. </p>

<p>There's no specific flags for <code>bitcoind</code> that you can use to control confirmations, it's all in your software's side. Generally if you're a merchant, you should avoid having a listening node (set <code>listen=0</code>) just to be on the safe side. Be sure to be using cold storage if your server accumulates a target-worthy amount of currency, by sending off to an address that the server does not know the private key of. </p>

<p>If you're not using <code>walletnotify</code> to control your internal accounting system, you probably should. </p>

CC BY-SA 3.0
2013-11-17T20:12:47.817Z
Stupid question, how do I go about setting listen=0 ? (How) can I pass this as an option when starting bitcoind?
Konstantin Schubert
CC BY-SA 3.0
2013-09-19T08:13:37.467Z
2013-09-19T08:19:50.727Z
2013-09-19T08:19:50.727Z
Anonymous
<p>I am providing a service that accepts Bitcoin. In order to speed things up a bit, I am planning to reduce the number of confirmations I require before I consider the money to have arrived. </p>

<p>I have read that it is quite safe to work with even a single confirmation if you take some precautions measures. What are those? </p>

<p>More specifically, with which options should I run bitcoind ? </p>

CC BY-SA 3.0
2013-09-19T09:51:56.660Z
You can mark the money as arrived straight away really. What you should not do is allow the money to be transferred out while confirmation are less than 3 or 5 or whatever. It depends what you service does? If you converting to fiat currency you want more confirmations. If you running a poker game it does not matter as your engine can backtrack any invalid transactions and you just disallow out transfers if an account has not fully matured the transactions. This will prevent hit and run fraud but allow legit users to experience fast deposits.
Piotr Kula
<confirmations><doublespend>
What precautions to take when working with only one or two confirmations?
Konstantin Schubert
# What precautions to take when working with only one or two confirmations?

(Asked by: username_0 on 2013-09-19)

I am providing a service that accepts Bitcoin. In order to speed things up a bit, I am planning to reduce the number of confirmations I require before I consider the money to have arrived.

I have read that it is quite safe to work with even a single confirmation if you take some precautions measures. What are those?

More specifically, with which options should I run bitcoind ?

**Tags:** confirmations, doublespend

> **Comments:**
> **username_1**: You can mark the money as arrived straight away really. What you should not do is allow the money to be transferred out while confirmation are less than 3 or 5 or whatever. It depends what you service does? If you converting to fiat currency you want more confirmations. If you running a poker game it does not matter as your engine can backtrack any invalid transactions and you just disallow out transfers if an account has not fully matured the transactions. This will prevent hit and run fraud but allow legit users to experience fast deposits.  

---

## 2 answers

### Answer by username_3 on 2013-09-19. Score: 7 | Accepted answer

At the moment there's very little orphaning of blocks, and next to no occurrence of two-block side chains. Unless you're dealing with large amounts (larger than two block rewards worth, probably), your chances of attack are incredibly incredibly low. If you're dealing with amounts less than a few BTC, I'd personally be happy accepting one-confirmation transactions.

There's no specific flags for `bitcoind` that you can use to control confirmations, it's all in your software's side. Generally if you're a merchant, you should avoid having a listening node (set `listen=0`) just to be on the safe side. Be sure to be using cold storage if your server accumulates a target-worthy amount of currency, by sending off to an address that the server does not know the private key of.

If you're not using `walletnotify` to control your internal accounting system, you probably should.

> **Comments:**
> **username_0**: Stupid question, how do I go about setting listen=0 ? (How) can I pass this as an option when starting bitcoind?  

---

### Answer by username_2 on 2013-09-19. Score: 3

There's a significant increase in the risk of being defrauded when the merchant accepts payment 0/unconfirmed and at the same time has bitcoind configured for incoming transactions. In that situation, the attacker can reach a near 100% success in double spending against the merchant simply by making a direct connection to that merchant's node and broadcasting one transaction to it and then to the rest of the network broadcasting a double spend transaction.

But when the merchant waits until there is at least one confirmation the this race attack risk essentially disappears.

To disable listening, the setting is "listen=0".

> **Comments:**
> **username_0**: I really liked your answer but I can only accept one. Sorry.  

---

