<p>I proffer that it would depend on the tools used to make the transaction and broadcast it. </p>

<p>Assuming use of something like <a href="https://play.google.com/store/apps/details?id=de.schildbach.wallet&amp;hl=en" rel="nofollow">Bitcoin Wallet for Android</a> or even a laptop running Bitcoin-Qt, the chances are <em>very</em> unlikely. </p>

<p>A malicious user would have to connect to the network with two devices simultaneously and broadcast the real transaction (the one being "sent" to the vendor) milliseconds after the malicious transaction. The vendor's client would have to see the real transaction before the malicious transaction, give the item to the malicious buyer, and depart company before realizing he's been had.</p>

<p>Simply put, a malicious user would have to be connected to more nodes in the network than the vendor and NOT be connected to any of the nodes to which the vendor is connected when broadcasting the malicious transaction, probably out at least one or two degrees of separation. This would ensure enough latency to ensure the vendor sees the real transaction first and surrenders the goods before the vendor's client says that other nodes think another transaction is of higher priority.</p>

<p>All of this can be avoided by waiting for a confirmation, but in real commerce, that may not feasible.</p>

CC BY-SA 3.0
2013-04-04T16:44:34.097Z
What happens when a node receives two conflicting transactions? Does it notify other nodes? Does it drop both or just one? If just one, is it first-come-first-served?
nivs
CC BY-SA 3.0
2013-04-05T01:08:43.813Z
My understanding is that it accepts the one with the earlier lock time. It does not notify other nodes in any way, it simply would drop the other transaction.
Colin Dean
CC BY-SA 3.0
2013-03-21T20:59:25.820Z
2013-03-21T20:59:25.820Z
Colin Dean
<p>When exchanging funds or services face-to-face, is there a risk of a double-spending attack? If there is, how could it be technically done?</p>

<security><exchanges><doublespend>
Is there a risk of double-spending when making a face-to-face transaction?
nivs
# Is there a risk of double-spending when making a face-to-face transaction?

(Asked by: username_0 on 2013-03-21)

When exchanging funds or services face-to-face, is there a risk of a double-spending attack? If there is, how could it be technically done?

**Tags:** security, exchanges, doublespend


---

## 1 answers

### Answer by username_1 on 2013-03-21. Score: 1 | Accepted answer

I proffer that it would depend on the tools used to make the transaction and broadcast it.

Assuming use of something like [Bitcoin Wallet for Android](https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en) or even a laptop running Bitcoin-Qt, the chances are *very* unlikely.

A malicious user would have to connect to the network with two devices simultaneously and broadcast the real transaction (the one being "sent" to the vendor) milliseconds after the malicious transaction. The vendor's client would have to see the real transaction before the malicious transaction, give the item to the malicious buyer, and depart company before realizing he's been had.

Simply put, a malicious user would have to be connected to more nodes in the network than the vendor and NOT be connected to any of the nodes to which the vendor is connected when broadcasting the malicious transaction, probably out at least one or two degrees of separation. This would ensure enough latency to ensure the vendor sees the real transaction first and surrenders the goods before the vendor's client says that other nodes think another transaction is of higher priority.

All of this can be avoided by waiting for a confirmation, but in real commerce, that may not feasible.

> **Comments:**
> **username_0**: What happens when a node receives two conflicting transactions? Does it notify other nodes? Does it drop both or just one? If just one, is it first-come-first-served?  
> **username_1**: My understanding is that it accepts the one with the earlier lock time. It does not notify other nodes in any way, it simply would drop the other transaction.  

---

