<p>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.</p>

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

CC BY-SA 3.0
2012-06-16T05:00:13.570Z
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
CC BY-SA 3.0
2012-06-16T05:02:42.927Z
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
CC BY-SA 3.0
2012-06-16T12:09:09.773Z
@StephenGornick you could use -addnode= multiple times.
ThePiachu
CC BY-SA 3.0
2012-09-17T23:44:44.027Z
Do I run the standard wallet-qt exe with command line switches. Would it work on MacOSX or Windows? Or is linux better?
makerofthings7
CC BY-SA 3.0
2012-09-18T03:59:06.010Z
@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
CC BY-SA 3.0
2012-06-15T08:54:51.073Z
2012-06-15T08:54:51.073Z
ThePiachu
<p>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.</p>

CC BY-SA 3.0
2012-07-10T18:46:16.170Z
2012-07-10T18:46:16.170Z
Michael Hampton
<p>BlockChain.info now provides a list of <a href="http://blockchain.info/hub-nodes" rel="nofollow">hub nodes</a>.  While there is no guarantee they will relay your transactions, connecting to several will likely ensure your transactions are propagated to many peers quickly.</p>

CC BY-SA 3.0
2012-10-02T04:55:30.287Z
Also, no idea if any of these are well connected, but they are nodes ranked in order of uptime:

 - http://bitcoin.sipa.be/seeds.txt
Stephen Gornick
CC BY-SA 3.0
2012-09-28T14:42:09.753Z
2012-09-28T14:42:09.753Z
Stephen Gornick
<p>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.</p>

<p>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.</p>

<p>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= ).</p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2012-06-15T04:03:12.277Z
If a limited number of nodes end up on a "recommended" list, will the demand for connecting to those nodes cause problems?
Highly Irregular
CC BY-SA 3.0
2012-06-16T05:03:31.647Z
Yes, I suppose that could be a problem.
Stephen Gornick
<attack><zero-confirmation><merchants><race-attack>
What nodes are best for lessening the risk of loss from a race attack
Stephen Gornick
# What nodes are best for lessening the risk of loss from a race attack

(Asked by: username_0 on 2012-06-15)

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?

**Tags:** attack, zero-confirmation, merchants, race-attack

> **Comments:**
> **username_1**: If a limited number of nodes end up on a "recommended" list, will the demand for connecting to those nodes cause problems?  
> **username_0**: Yes, I suppose that could be a problem.  

---

## 3 answers

### Answer by username_2 on 2012-06-15. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: 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.  
> **username_2**: @username_0 you could use -addnode= multiple times.  
> **username_3**: Do I run the standard wallet-qt exe with command line switches. Would it work on MacOSX or Windows? Or is linux better?  
> **username_2**: @username_3 It works on the standard BitcoinQT client, and probably a few others. It should work under Windows, MacOS and Linux just the same.  

---

### Answer by username_4 on 2012-07-10. Score: 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.


---

### Answer by username_0 on 2012-09-28. Score: 1

BlockChain.info now provides a list of [hub nodes](http://blockchain.info/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.

> **Comments:**
> **username_0**: Also, no idea if any of these are well connected, but they are nodes ranked in order of uptime:   - http://bitcoin.sipa.be/seeds.txt  

---

