<p>To essentially eliminate any risk due to <a href="http://en.bitcoin.it/wiki/Double-spending" rel="nofollow">double spending</a>, the recommended level of confirmations is six.</p>

<p>For most transactions such as those to a bricks and mortar merchant, payment might be accepted immediately (with 0 confirmations), but that exposes the merchant to a small degree of double-spending risk.</p>

<p>A recommendation for merchants running their own node is to have the configuration where there are no incoming connection and to explicitly have an outgoing connection to a well-connected node.  </p>

<p>Thus, properly configured this way, the merchant is not much at risk of double spending because either the transaction was broadcast and it reached the well-connected node that the merchant connects to or it didn't and the merchant doesn't know about it until communications from the party attempting to pay can be re-established with the outside world.</p>

<p>In that scenario, bitcoin fares no worse than any other merchant payment system as those require authorization from <a href="https://www.chasepaymentech.com/connectivity.html" rel="nofollow">connected sources</a> as well.</p>

<p>The amount of data to receive blockchain data is relatively little -- under 100MB per day.  Thus even a single dialup modem connection is all that would be needed and that node could then serve all other nodes connected locally.</p>

<p>Additionally, if mobile communications are present, the merchant could simply use mobile notification from a hosted service and not run using a node at all. </p>

<p>There is a business solution not a technical one to the specific scenario requested.  Just as a hotel will accept a check from a guest even when it doesn't have a guarantee that the check won't bounce, a merchant can accept a bitcoin transaction even when there are no communications by adding a layer above (e.g., verifying identification, getting approval to charge against a backup payment method using a credit card, not selling anything of high value during the communications outage, etc.)</p>

CC BY-SA 3.0
2012-09-17T12:39:43.967Z
Thank you. Who are the "well connected nodes", or how would I create one?  Also what software should I use to have my own node in this case?  Just the bit coin wallet?
makerofthings7
CC BY-SA 3.0
2012-09-17T17:54:37.593Z
Mining pools would be one example.  Suggestions ar here: http://bitcoin.stackexchange.com/q/3961/153 This service could be offered commercially if there is demand.  As far as how to provide this yourself, yes, simply using the -nolisten and -connect= to pools on a trusted node will result in a "well connected node" all your own.  Here's the syntax: http://en.bitcoin.it/wiki/Running_Bitcoin
Stephen Gornick
CC BY-SA 3.0
2012-09-17T02:59:19.320Z
2012-09-17T03:17:20.727Z
2012-09-17T03:17:20.727Z
Stephen Gornick
<p>The easiest way to protect oneself against double-spend attack is to ignore all transactions that don't have at least six confirmations. Changing that many blocks through a Finney attack would be prohibitively expensive and quite implausible.</p>

CC BY-SA 3.0
2012-09-17T12:36:36.980Z
If a confirmation means the block was added, that means 6 blocks later, right?  How would I know if a longer chain replaced my confirmed blocks which is more likely to happen in this situation?
makerofthings7
CC BY-SA 3.0
2012-09-17T17:47:35.253Z
In your scenario of a disconnected island, there isn't enough mining occurring to solve maybe even a single block nonetheless six blocks.   So you would never get to six confirmations until connectivity is re-established.  i.e., Bitcoin doesn't really work for this scenario of being not connected with "the rest of the world" unless your counterparty can be trusted.
Stephen Gornick
CC BY-SA 3.0
2012-09-17T22:44:24.190Z
@makerofthings7 When other blocks replace your blocks, you will see your transactions losing any confirmations. Provided they are still valid, they should be included in the future blocks created by the main chain.
ThePiachu
CC BY-SA 3.0
2012-09-17T03:55:33.440Z
2012-09-17T03:55:33.440Z
ThePiachu
<p>I'm a vendor who is interested in protecting myself from double spend attacks.</p>

<p>What software, configuration, connectivity, or timeout is required to mitigate this risk?</p>

<p>Namely, how would I protect myself if a continential communications blackout were to occur, as <a href="https://bitcoin.stackexchange.com/q/1738/1878">described here</a>.</p>

<p>This could occur if I'm accepting payment on a satellite link, as often occurs on boat-casinos, islands (Hawaii), or in 3rd world countries.</p>

<network><doublespend><blockchain-fork><risk-mitigation>
Without being continuously connected to the network, how can I protect from Double Spend attacks?
makerofthings7
# Without being continuously connected to the network, how can I protect from Double Spend attacks?

(Asked by: username_0 on 2012-09-16)

I'm a vendor who is interested in protecting myself from double spend attacks.

What software, configuration, connectivity, or timeout is required to mitigate this risk?

Namely, how would I protect myself if a continential communications blackout were to occur, as [described here](https://bitcoin.stackexchange.com/q/1738/1878).

This could occur if I'm accepting payment on a satellite link, as often occurs on boat-casinos, islands (Hawaii), or in 3rd world countries.

**Tags:** network, doublespend, blockchain-fork, risk-mitigation


---

## 2 answers

### Answer by username_1 on 2012-09-17. Score: 2 | Accepted answer

To essentially eliminate any risk due to [double spending](http://en.bitcoin.it/wiki/Double-spending), the recommended level of confirmations is six.

For most transactions such as those to a bricks and mortar merchant, payment might be accepted immediately (with 0 confirmations), but that exposes the merchant to a small degree of double-spending risk.

A recommendation for merchants running their own node is to have the configuration where there are no incoming connection and to explicitly have an outgoing connection to a well-connected node.

Thus, properly configured this way, the merchant is not much at risk of double spending because either the transaction was broadcast and it reached the well-connected node that the merchant connects to or it didn't and the merchant doesn't know about it until communications from the party attempting to pay can be re-established with the outside world.

In that scenario, bitcoin fares no worse than any other merchant payment system as those require authorization from [connected sources](https://www.chasepaymentech.com/connectivity.html) as well.

The amount of data to receive blockchain data is relatively little -- under 100MB per day. Thus even a single dialup modem connection is all that would be needed and that node could then serve all other nodes connected locally.

Additionally, if mobile communications are present, the merchant could simply use mobile notification from a hosted service and not run using a node at all.

There is a business solution not a technical one to the specific scenario requested. Just as a hotel will accept a check from a guest even when it doesn't have a guarantee that the check won't bounce, a merchant can accept a bitcoin transaction even when there are no communications by adding a layer above (e.g., verifying identification, getting approval to charge against a backup payment method using a credit card, not selling anything of high value during the communications outage, etc.)

> **Comments:**
> **username_0**: Thank you. Who are the "well connected nodes", or how would I create one?  Also what software should I use to have my own node in this case?  Just the bit coin wallet?  
> **username_1**: Mining pools would be one example.  Suggestions ar here: http://bitcoin.stackexchange.com/q/3961/153 This service could be offered commercially if there is demand.  As far as how to provide this yourself, yes, simply using the -nolisten and -connect= to pools on a trusted node will result in a "well connected node" all your own.  Here's the syntax: http://en.bitcoin.it/wiki/Running_Bitcoin  

---

### Answer by username_2 on 2012-09-17. Score: 1

The easiest way to protect oneself against double-spend attack is to ignore all transactions that don't have at least six confirmations. Changing that many blocks through a Finney attack would be prohibitively expensive and quite implausible.

> **Comments:**
> **username_0**: If a confirmation means the block was added, that means 6 blocks later, right?  How would I know if a longer chain replaced my confirmed blocks which is more likely to happen in this situation?  
> **username_1**: In your scenario of a disconnected island, there isn't enough mining occurring to solve maybe even a single block nonetheless six blocks.   So you would never get to six confirmations until connectivity is re-established.  i.e., Bitcoin doesn't really work for this scenario of being not connected with "the rest of the world" unless your counterparty can be trusted.  
> **username_2**: @username_0 When other blocks replace your blocks, you will see your transactions losing any confirmations. Provided they are still valid, they should be included in the future blocks created by the main chain.  

---

