<p>Conflicting transactions are simply two or more transactions that spent the same UTXO in its inputs (i.e. doublespending).</p>

<p>The only remedy is to not treat a transaction as successful until it has a number of confirmation that satisfies you. </p>

<p>It is impossible to recover from a successful doublespend attack should the conflicting transaction be included in the blockchain.</p>

CC BY-SA 3.0
2016-12-08T21:49:07.247Z
Looking a the inputs and outputs, does it look like the transaction was initiated with zero fees? If so it seems strange as most wallets commonly do not initiate transactions with low/no fees.
Fakeer
CC BY-SA 3.0
2016-12-09T06:01:16.293Z
I don't see how does that help. The point is you can create transactions that pay zero or more fees. Whether or not they confirm is another matter.
rny
CC BY-SA 3.0
2016-12-09T18:31:18.040Z
Thanks for the responses. Due to mostly smaller sized transactions the merchant cannot wait for confirmations. Given this primary constraint I'm trying to find out how to take precautions to minimize double spend attacks. That's why I was trying to identify some parameters that can be used for defence - e.g. not accepting zero fee Txs. A reasonable fee having a high chance of being propagated quickly (I understand that the same inputs can be sent in two txs one with higher fees)
Fakeer
CC BY-SA 3.0
2016-12-08T02:47:07.663Z
2016-12-08T02:47:07.663Z
rny
<p>An online store recently received a payment via a wallet-to-wallet BTC payment. But after a while the total_received value went down to zero on blockchain.info. Now the address cannot be sweeped as there is no balance so the merchant assumed that the money is lost/stolen.</p>

<p>Tradeblock seems to have more details for this transaction:</p>

<p><a href="https://tradeblock.com/bitcoin/address/1L1MSa36vaSeo8myBcGfGA3UddGDitZXai" rel="nofollow noreferrer">https://tradeblock.com/bitcoin/address/1L1MSa36vaSeo8myBcGfGA3UddGDitZXai</a></p>

<p>Here's another similar one "suspected" from the same user:</p>

<p><a href="https://tradeblock.com/bitcoin/address/1KsVJ1ySWVmVD5uci4mSuT98Uj65VpEzD" rel="nofollow noreferrer">https://tradeblock.com/bitcoin/address/1KsVJ1ySWVmVD5uci4mSuT98Uj65VpEzD</a></p>

<p>(icon at the rightmost column of each transaction has more details)</p>

<p>Can someone pls explain the anatomy of this - how to interpret and how to rectify (if at all possible).</p>

<unconfirmed-transactions>
What are conflicting transactions? Does it mean BTC lost permanently?
Fakeer
# What are conflicting transactions? Does it mean BTC lost permanently?

(Asked by: username_0 on 2016-12-08)

An online store recently received a payment via a wallet-to-wallet BTC payment. But after a while the total\_received value went down to zero on blockchain.info. Now the address cannot be sweeped as there is no balance so the merchant assumed that the money is lost/stolen.

Tradeblock seems to have more details for this transaction:

<https://tradeblock.com/bitcoin/address/1L1MSa36vaSeo8myBcGfGA3UddGDitZXai>

Here's another similar one "suspected" from the same user:

<https://tradeblock.com/bitcoin/address/1KsVJ1ySWVmVD5uci4mSuT98Uj65VpEzD>

(icon at the rightmost column of each transaction has more details)

Can someone pls explain the anatomy of this - how to interpret and how to rectify (if at all possible).

**Tags:** unconfirmed-transactions


---

## 1 answers

### Answer by username_1 on 2016-12-08. Score: 1

Conflicting transactions are simply two or more transactions that spent the same UTXO in its inputs (i.e. doublespending).

The only remedy is to not treat a transaction as successful until it has a number of confirmation that satisfies you.

It is impossible to recover from a successful doublespend attack should the conflicting transaction be included in the blockchain.

> **Comments:**
> **username_0**: Looking a the inputs and outputs, does it look like the transaction was initiated with zero fees? If so it seems strange as most wallets commonly do not initiate transactions with low/no fees.  
> **username_1**: I don't see how does that help. The point is you can create transactions that pay zero or more fees. Whether or not they confirm is another matter.  
> **username_0**: Thanks for the responses. Due to mostly smaller sized transactions the merchant cannot wait for confirmations. Given this primary constraint I'm trying to find out how to take precautions to minimize double spend attacks. That's why I was trying to identify some parameters that can be used for defence - e.g. not accepting zero fee Txs. A reasonable fee having a high chance of being propagated quickly (I understand that the same inputs can be sent in two txs one with higher fees)  

---

