<p>Fundamentally, this is why nobody should be accepting zero confirmations, until the payment has confirmations it’s not really a payment made. This is generally referred to as double spending, as clearly only a single payment can confirm in your scenario. If stores want to accept payments in an unsafe fashion, that’s their risk to bear and insure for. </p>

<p>Technology like Lightning can be used to make instantly confirming transactions safely if this sort of retail experience is desirable, though this comes with its own hurdles. </p>

CC BY-SA 4.0
2019-03-25T05:17:00.657Z
That's an excellent answer, thanks! But you seem to say that it can happen but risk can be minimized if you're savvy and experienced (trap for the unwary merchant.) (a) even a low fee is no guarantee of timely processing. Knowing the "right" fee to use presents a high barrier to entry for users compared to the standard fees offered by centralized systems like credit cards - costly perhaps but at least everyone can set expectations. (b) Good point about Lightning. But aren't payment channels more useful for recurring transactions with the same parties and limitations like prefunding?
rossmclochness
CC BY-SA 4.0
2019-03-25T04:29:59.977Z
2019-03-25T04:29:59.977Z
Claris
<p>I've tried to find a solid answer to this transaction ordering question and the practical and technical issues that do not seem solved.</p>

<p>My understanding is that after I create a transaction, I can choose to add a fee for miners to pick up my transaction. I submit it to the network for propagation. Miners look in the unspent transaction pool and choose which they want to include in a new block. I saw this Tweet which seems to confirm a transaction ordering problem - using the same transaction input for two transactions with the latter being a high fee and that one confirmed first. I don't understand why several responders seem to to believe this isn't a problem.</p>

<p><a href="https://twitter.com/alexbosworth/status/1028031387201236992?lang=en" rel="nofollow noreferrer">https://twitter.com/alexbosworth/status/1028031387201236992?lang=en</a></p>

<p>I am near 2 stores that accept Bitcoin. I spend an input at Costco with no or a little fee. It hangs in the mempool like above. An hour later I am at BestBuy and spend the same input but include a fee -- and that transaction gets picked up and processed first by a happy miner.</p>

<p>1) Even if Costco waited an hour, there is no guarantee that my earlier transaction will be confirmed in a block in 10 minutes or 210 minutes. It's still too long for BestBuy to wait 5 additional confirmations after the first.</p>

<p>2) There is no guarantee that even if that the first Costco transaction was picked up by a miner, that a second miner that picked up the BestBuy transaction a little later couldn't complete a block which would eventually be in the longer chain. In that case too, the first in transaction eventually gets bounced off the chain. </p>

CC BY-SA 4.0
2019-03-25T04:30:10.657Z
Let’s try this again.
Claris
<blockchain><transaction-fees><unconfirmed-transactions>
Bitcoin optional fees create transaction ordering problems?
rossmclochness
# Bitcoin optional fees create transaction ordering problems?

(Asked by: username_0 on 2019-03-25)

I've tried to find a solid answer to this transaction ordering question and the practical and technical issues that do not seem solved.

My understanding is that after I create a transaction, I can choose to add a fee for miners to pick up my transaction. I submit it to the network for propagation. Miners look in the unspent transaction pool and choose which they want to include in a new block. I saw this Tweet which seems to confirm a transaction ordering problem - using the same transaction input for two transactions with the latter being a high fee and that one confirmed first. I don't understand why several responders seem to to believe this isn't a problem.

<https://twitter.com/alexbosworth/status/1028031387201236992?lang=en>

I am near 2 stores that accept Bitcoin. I spend an input at Costco with no or a little fee. It hangs in the mempool like above. An hour later I am at BestBuy and spend the same input but include a fee -- and that transaction gets picked up and processed first by a happy miner.

1) Even if Costco waited an hour, there is no guarantee that my earlier transaction will be confirmed in a block in 10 minutes or 210 minutes. It's still too long for BestBuy to wait 5 additional confirmations after the first.

2) There is no guarantee that even if that the first Costco transaction was picked up by a miner, that a second miner that picked up the BestBuy transaction a little later couldn't complete a block which would eventually be in the longer chain. In that case too, the first in transaction eventually gets bounced off the chain.

**Tags:** blockchain, transaction-fees, unconfirmed-transactions

> **Comments:**
> **username_1**: Let’s try this again.  

---

## 1 answers

### Answer by username_1 on 2019-03-25. Score: 1

Fundamentally, this is why nobody should be accepting zero confirmations, until the payment has confirmations it’s not really a payment made. This is generally referred to as double spending, as clearly only a single payment can confirm in your scenario. If stores want to accept payments in an unsafe fashion, that’s their risk to bear and insure for.

Technology like Lightning can be used to make instantly confirming transactions safely if this sort of retail experience is desirable, though this comes with its own hurdles.

> **Comments:**
> **username_0**: That's an excellent answer, thanks! But you seem to say that it can happen but risk can be minimized if you're savvy and experienced (trap for the unwary merchant.) (a) even a low fee is no guarantee of timely processing. Knowing the "right" fee to use presents a high barrier to entry for users compared to the standard fees offered by centralized systems like credit cards - costly perhaps but at least everyone can set expectations. (b) Good point about Lightning. But aren't payment channels more useful for recurring transactions with the same parties and limitations like prefunding?  

---

