7

A successful race attack is one where the payment recipient's node receives a spend transaction yet the next block that is mined has a different transaction that spends the same coin. Thus the payment recipient's transaction will not confirm and the recipient never receives the funds.

This is an explicit attack to double spend. The recommended protection is to not accept payment on 0/unconfirmed if there is no recourse (e.g., an anonymous buyer who makes off with the item traded before the double spend can be detected.) For some types of businesses (e.g., retail, low-value goods purchased in-person, face-to-face), the risk is acceptable.

The recommendation for the merchant is to disable listening on the client (using -nolisten) and to explicitly connect to a well connected node (using -connect= ).

How does a merchant know which nodes are well-connected. Because pool mining solves over half the blocks, ideally the well-connected node is one that reaches these pools first, so that if a transaction is relayed by the well-connected node then the odds are it will end up being the transaction mined by a pool even if there was an attempted double-spend.

Are there any nodes that are known to be good for relaying transactions to the pools, and thus preventing a race attack from being successful?

|improve this question
  • 2
    If a limited number of nodes end up on a "recommended" list, will the demand for connecting to those nodes cause problems? – Highly Irregular Jun 15 '12 at 4:03
  • Yes, I suppose that could be a problem. – Stephen Gornick Jun 16 '12 at 5:03
3

It would be recommended to connect directly to most of the major pools. This way one doesn't need to rely on any other nodes to relay the informations.

However, you should note that the conflicting transaction could already be pre-mined, rendering such precautions useless.

|improve this answer
  • 1
    Right, the pre-mined (Finney) attack is a different threat model. The race attack can be carried out by anyone and because the merchant doesn't know about failed attempts, it can be repeated by the thief until successful. So the chances of a Finney attack occurring are much lower than the chances of a race attack. – Stephen Gornick Jun 16 '12 at 5:00
  • The -connect= is for a single address, so there would only be one connection. The would either require choosing a single pool to connect to or, to a well connected node that has connections to each of the pools. – Stephen Gornick Jun 16 '12 at 5:02
  • @StephenGornick you could use -addnode= multiple times. – ThePiachu Jun 16 '12 at 12:09
  • Do I run the standard wallet-qt exe with command line switches. Would it work on MacOSX or Windows? Or is linux better? – technology_is_overrated Sep 17 '12 at 23:44
  • @makerofthings7 It works on the standard BitcoinQT client, and probably a few others. It should work under Windows, MacOS and Linux just the same. – ThePiachu Sep 18 '12 at 3:59
1

One possible way to deal with this is to set up a second bitcoind on a separate server, which is well connected to the network (i.e. not behind NAT or something strange like that) whose sole purpose is to listen to the network and take connections from your first bitcoind.

|improve this answer
1

BlockChain.info now provides a list of hub nodes. While there is no guarantee they will relay your transactions, connecting to several will likely ensure your transactions are propagated to many peers quickly.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.