1

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.

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.

Community
  • 1
makerofthings7
  • 12,726
  • 11
  • 62
  • 130

2 Answers2

2

To essentially eliminate any risk due to 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 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.)

Stephen Gornick
  • 27,040
  • 12
  • 67
  • 141
  • 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 Sep 17 '12 at 12:39
  • 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 Sep 17 '12 at 17:54
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.

ThePiachu
  • 43,091
  • 25
  • 139
  • 348
  • 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 Sep 17 '12 at 12:36
  • 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 Sep 17 '12 at 17:47
  • @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 Sep 17 '12 at 22:44