<p>The bottom line is that there is no way for you to safely accept zero confirmation transactions. </p>

<blockquote>
  <p>What happens if a miner (which has transaction A in his main memory) gets the conflicting transaction B?</p>
</blockquote>

<p>Depends on what software the miner is running and how they have configured it. </p>

<ul>
<li><p>Some nodes will reject it. </p></li>
<li><p>Some nodes will accept it.</p></li>
<li><p>Some nodes will accept it conditionally. </p></li>
</ul>

<p>There's no knowing what people are running on mining nodes or what rules they have.</p>

<blockquote>
  <p>Would a miner throw away transaction A and include B, if B has higher transaction fees, a smaller size in bytes, or of other attribute?</p>
</blockquote>

<p>Ditto.</p>

<blockquote>
  <p>Can a merchant be sure, that transaction A will be confirmed, if it is propagated successfully to let's say all or most miners?</p>
</blockquote>

<p>Absolutely not. </p>

<p>An alternative can be mined at any time, invalidating the original. This attack has been used in the real world to defraud websites of their Bitcoin payments to the tune of millions of dollars. Successful double spends can even happen once the transaction has been included in a block, which is why a large number of confirmations is suggested for people accepting Bitcoin as payment for services.</p>

CC BY-SA 3.0
2015-11-13T14:28:56.933Z
Hmm, so if this is all true, reliable transactions cannot be done in a POS setting.  Either one is doing something like payment channels, or living with the risk. Nobody would wait for more than 10 minutes at the counter after a purchase.
Stefan
CC BY-SA 3.0
2015-11-13T14:42:35.007Z
however there is this company blockcypher, which calculates a confidence value for an unconfirmed transaction. What other approach could be used, if not how far a transaction is propagated into the network to calculate such a value?
Stefan
CC BY-SA 3.0
2015-11-13T14:55:09.433Z
It's easy to sell nonsense metrics if people don't understand what they mean. Miners can include whatever they want, irrespective of what people think is in peoples memory pools.
Claris
CC BY-SA 3.0
2015-11-13T16:32:54.900Z
if a miner finds a double spend attempt, will he propagate the transaction further or not? Is there anything special he is doing?
Stefan
CC BY-SA 3.0
2015-11-13T22:21:26.540Z
That's up to the miner.
Claris
CC BY-SA 3.0
2015-11-13T14:13:57.537Z
2015-11-13T14:13:57.537Z
Claris
<p>Relying on an unconfirmed transaction is much riskier than relying on 1-confirmed transaction.  And in turn, relying on a 1-confirmed transaction is risker than relying on a 2-confirmed transaction.</p>

<p>This will always be a choice best made on empirical data.  One of the more disappointing ideas is that, because 0-conf is less safe, all use of it should be eradicated.</p>

CC BY-SA 3.0
2015-11-17T15:55:14.777Z
2015-11-17T15:55:14.777Z
Tom Harding
<p>I am developing a point of sale bitcoin app, which should accept "fast" transactions (~30 sec for merchant to accept). I researched double spending questions here already, but it is still unclear to me, what happens within the time frame before a transaction is actually included into a block.</p>

<p>Considering the case of a double spend attempt, where an attacker needs to pay to a merchant. The attacker creates and propagates a respective transaction A into the the bitcoin network. Transaction A is added to the main memory of mining nodes and is "waiting" for inclusion into one of the next blocks. The merchant is informed of the propagation of transaction A by the nodes he is connected to. Before transaction A is actually included in a block, the attacker creates and propagates another transaction B, which has the same inputs as A (double spend).</p>

<ul>
<li>What happens if a miner (which has transaction A in his main memory) gets the conflicting transaction B?</li>
<li>Can a merchant be sure, that transaction A will be confirmed, if it is propagated successfully to let's say all or most miners?</li>
<li>Would a miner throw away transaction A and include B, if B has higher transaction fees, a smaller size in bytes, or of other attribute?</li>
</ul>

CC BY-SA 3.0
2015-11-13T14:22:30.730Z
Basically what you'd need is something like the Lightning Network. But that is by no means operational yet and will likely take more than a year before you can reasonably start testing. And longer before there's enough adoption by wallets and users.
Jannes
<doublespend><zero-confirmation>
0/confirmation race attack double spend transactions
Stefan
# 0/confirmation race attack double spend transactions

(Asked by: username_0 on 2015-11-13)

I am developing a point of sale bitcoin app, which should accept "fast" transactions (~30 sec for merchant to accept). I researched double spending questions here already, but it is still unclear to me, what happens within the time frame before a transaction is actually included into a block.

Considering the case of a double spend attempt, where an attacker needs to pay to a merchant. The attacker creates and propagates a respective transaction A into the the bitcoin network. Transaction A is added to the main memory of mining nodes and is "waiting" for inclusion into one of the next blocks. The merchant is informed of the propagation of transaction A by the nodes he is connected to. Before transaction A is actually included in a block, the attacker creates and propagates another transaction B, which has the same inputs as A (double spend).

* What happens if a miner (which has transaction A in his main memory) gets the conflicting transaction B?
* Can a merchant be sure, that transaction A will be confirmed, if it is propagated successfully to let's say all or most miners?
* Would a miner throw away transaction A and include B, if B has higher transaction fees, a smaller size in bytes, or of other attribute?

**Tags:** doublespend, zero-confirmation

> **Comments:**
> **username_1**: Basically what you'd need is something like the Lightning Network. But that is by no means operational yet and will likely take more than a year before you can reasonably start testing. And longer before there's enough adoption by wallets and users.  

---

## 2 answers

### Answer by username_2 on 2015-11-13. Score: 2 | Accepted answer

The bottom line is that there is no way for you to safely accept zero confirmation transactions.

> What happens if a miner (which has transaction A in his main memory) gets the conflicting transaction B?

Depends on what software the miner is running and how they have configured it.

* Some nodes will reject it.
* Some nodes will accept it.
* Some nodes will accept it conditionally.

There's no knowing what people are running on mining nodes or what rules they have.

> Would a miner throw away transaction A and include B, if B has higher transaction fees, a smaller size in bytes, or of other attribute?

Ditto.

> Can a merchant be sure, that transaction A will be confirmed, if it is propagated successfully to let's say all or most miners?

Absolutely not.

An alternative can be mined at any time, invalidating the original. This attack has been used in the real world to defraud websites of their Bitcoin payments to the tune of millions of dollars. Successful double spends can even happen once the transaction has been included in a block, which is why a large number of confirmations is suggested for people accepting Bitcoin as payment for services.

> **Comments:**
> **username_0**: Hmm, so if this is all true, reliable transactions cannot be done in a POS setting.  Either one is doing something like payment channels, or living with the risk. Nobody would wait for more than 10 minutes at the counter after a purchase.  
> **username_0**: however there is this company blockcypher, which calculates a confidence value for an unconfirmed transaction. What other approach could be used, if not how far a transaction is propagated into the network to calculate such a value?  
> **username_2**: It's easy to sell nonsense metrics if people don't understand what they mean. Miners can include whatever they want, irrespective of what people think is in peoples memory pools.  
> **username_0**: if a miner finds a double spend attempt, will he propagate the transaction further or not? Is there anything special he is doing?  
> **username_2**: That's up to the miner.  

---

### Answer by username_3 on 2015-11-17. Score: 0

Relying on an unconfirmed transaction is much riskier than relying on 1-confirmed transaction. And in turn, relying on a 1-confirmed transaction is risker than relying on a 2-confirmed transaction.

This will always be a choice best made on empirical data. One of the more disappointing ideas is that, because 0-conf is less safe, all use of it should be eradicated.


---

