<p>The answer is actually that you will receive a negative confirmation count in this case. (The bitcoin documentation is just terrible..)</p>

<p>See the bitcoin core release notes of 0.12.0 - section "Wallet: Negative confirmations and conflict detection"</p>

<p><a href="https://bitcoin.org/en/release/v0.12.0" rel="nofollow noreferrer">https://bitcoin.org/en/release/v0.12.0</a></p>

<p><strong>update note</strong>: In case of a negative confirmation (conflict detected) be sure to fetch all parent tx of that tx and see if that one got confirmed</p>

CC BY-SA 4.0
2017-04-04T17:37:35.647Z
2019-02-12T16:11:31.790Z
2019-02-12T16:11:31.790Z
tobi
<p>Before you mark your question 'answered' consider this:</p>
<p>If your <em>bitcon client</em> does not see tx YYY but only sees XXX broadcast-ed then it would seem that only the block your client stored holds the reference to txid YYY (which your client never stored).</p>
<p>In your answer you point to <a href="https://bitcoin.org/en/release/v0.12.0#wallet-negative-confirmations-and-conflict-detection" rel="nofollow noreferrer">https://bitcoin.org/en/release/v0.12.0#wallet-negative-confirmations-and-conflict-detection</a> as the method that comes to the rescue ... In thier example scenario <code>transaction B</code> <em>'beats'</em> <code>transaction A</code> in a race to spend the same inputs ...</p>
<p>This method of detection works if your client has seen both network broadcasts of XXX (<code>transaction A</code>) and YYY (<code>transaction B</code>) (because this would be a double spend where YYY beat XXX!)</p>
<p>But seen as your client has never heard of YYY (apart from it's <em><strong>dead-end</strong></em> reference in one block) <strong>how will the client be able to use this method when tx YYY was recorded/saved/stored in your PC drive's memory as XXX?</strong></p>
<hr />
<p>My answer (if you can confirm that <strong>tx</strong> YYY is un-find-able by your client alone) is;</p>
<blockquote>
<p>It looks like some/many miners are changing txids (through malleability)</p>
<p>Testnet3 might be <em><strong>broken/under-un-intentional-attack-from-unsafe-code</strong></em> because malleated txids in blocks point to nothing stored in memory, while the txs that <em>are</em> stored are vaild spends - the txid is not always present in the block.</p>
<p><em>... like the miner is kind of decapitating some txs</em></p>
</blockquote>
<p>related: <a href="https://bitcoin.stackexchange.com/questions/52571/testnet3-frequent-tx-malleability">testnet3 frequent tx malleability</a> and <a href="https://bitcoin.stackexchange.com/questions/52575/how-did-blockr-io-see-this">How did blockr.io see this?</a></p>

CC BY-SA 3.0
2017-04-04T20:45:38.137Z
I am listening to the network in a completely different way to you and seeing the same thing! I'm not saying I am correct but, if you can prove this answer wrong that would be interesting! I would wonder what voodoo magic is going on here!
Ben Muircroft
CC BY-SA 3.0
2017-04-04T20:25:55.300Z
2017-04-04T21:27:45.383Z
2020-06-16T11:10:03.350Z
Ben Muircroft
<p>Transactions in the testnet are right now almost always double spent with a new txid (possible due to tx malleability). This is actually quite nice for testing purposes. </p>

<p>So I'm wondering - when I did a payment and have txId 'XXX' this payment sometimes gets confirmed with a new txId 'YYY' that I don't know of. How can I (using bitcoind json-rpc) find out that my payment with txId 'XXX' got confirmed?</p>

CC BY-SA 3.0
2017-04-04T17:37:19.000Z
im seeing the same! I see my pushed utx broadcasted on the network then later its in the block with different txid (i never see the altered utx broadcasted, I think the miners are changing them when they put them in the block!?)
Ben Muircroft
CC BY-SA 3.0
2017-04-04T17:39:19.083Z
It's not necessarily the miners. Anyone can change the signatures of the transaction slightly in a way that they will still be valid and this way generate a new tx hash. That this is possible is called transaction malleability. I guess someone is just doing this to all the transactions that are broadcasted in the testnet right now and somehow manages it to get them through before you're most of the time. See my answer on how to handle it.
tobi
CC BY-SA 3.0
2017-04-04T17:40:56.800Z
i never see the altered utx broadcasted
Ben Muircroft
CC BY-SA 3.0
2017-04-04T17:41:45.013Z
Neither do I. I think your own client rejects it because you already have that transaction. But when other clients see the conflicting transaction first they will reject yours
tobi
CC BY-SA 3.0
2017-04-04T17:44:49.143Z
XXX becomes YYY there are not 2 transactions - if there were you would have to see both broadcasted! Instead you only see XXX before it becomes YYY in the block
Ben Muircroft
CC BY-SA 3.0
2017-04-04T22:35:50.997Z
look at this dude! http://bitcoin.stackexchange.com/a/52576/14316 propper interesting (about us not seeing YYY broadcasted!)
Ben Muircroft
<json-rpc><unconfirmed-transactions><doublespend><transaction-verification><transaction-malleability>
How confirm my own doublespend transaction got confirmed
tobi
# How confirm my own doublespend transaction got confirmed

(Asked by: username_0 on 2017-04-03)

Transactions in the testnet are right now almost always double spent with a new txid (possible due to tx malleability). This is actually quite nice for testing purposes.

So I'm wondering - when I did a payment and have txId 'XXX' this payment sometimes gets confirmed with a new txId 'YYY' that I don't know of. How can I (using bitcoind json-rpc) find out that my payment with txId 'XXX' got confirmed?

**Tags:** json-rpc, unconfirmed-transactions, doublespend, transaction-verification, transaction-malleability

> **Comments:**
> **username_1**: im seeing the same! I see my pushed utx broadcasted on the network then later its in the block with different txid (i never see the altered utx broadcasted, I think the miners are changing them when they put them in the block!?)  
> **username_0**: It's not necessarily the miners. Anyone can change the signatures of the transaction slightly in a way that they will still be valid and this way generate a new tx hash. That this is possible is called transaction malleability. I guess someone is just doing this to all the transactions that are broadcasted in the testnet right now and somehow manages it to get them through before you're most of the time. See my answer on how to handle it.  
> **username_1**: i never see the altered utx broadcasted  
> **username_0**: Neither do I. I think your own client rejects it because you already have that transaction. But when other clients see the conflicting transaction first they will reject yours  
> **username_1**: XXX becomes YYY there are not 2 transactions - if there were you would have to see both broadcasted! Instead you only see XXX before it becomes YYY in the block  
> **username_1**: look at this dude! http://bitcoin.stackexchange.com/a/52576/14316 propper interesting (about us not seeing YYY broadcasted!)  

---

## 2 answers

### Answer by username_0 on 2017-04-04. Score: 0 | Accepted answer

The answer is actually that you will receive a negative confirmation count in this case. (The bitcoin documentation is just terrible..)

See the bitcoin core release notes of 0.12.0 - section "Wallet: Negative confirmations and conflict detection"

<https://bitcoin.org/en/release/v0.12.0>

**update note**: In case of a negative confirmation (conflict detected) be sure to fetch all parent tx of that tx and see if that one got confirmed


---

### Answer by username_1 on 2017-04-04. Score: 0

Before you mark your question 'answered' consider this:

If your *bitcon client* does not see tx YYY but only sees XXX broadcast-ed then it would seem that only the block your client stored holds the reference to txid YYY (which your client never stored).

In your answer you point to <https://bitcoin.org/en/release/v0.12.0#wallet-negative-confirmations-and-conflict-detection> as the method that comes to the rescue ... In thier example scenario `transaction B` *'beats'* `transaction A` in a race to spend the same inputs ...

This method of detection works if your client has seen both network broadcasts of XXX (`transaction A`) and YYY (`transaction B`) (because this would be a double spend where YYY beat XXX!)

But seen as your client has never heard of YYY (apart from it's ***dead-end*** reference in one block) **how will the client be able to use this method when tx YYY was recorded/saved/stored in your PC drive's memory as XXX?**

---

My answer (if you can confirm that **tx** YYY is un-find-able by your client alone) is;

> It looks like some/many miners are changing txids (through malleability)
>
> Testnet3 might be ***broken/under-un-intentional-attack-from-unsafe-code*** because malleated txids in blocks point to nothing stored in memory, while the txs that *are* stored are vaild spends - the txid is not always present in the block.
>
> *... like the miner is kind of decapitating some txs*

related: [testnet3 frequent tx malleability](https://bitcoin.stackexchange.com/questions/52571/testnet3-frequent-tx-malleability) and [How did blockr.io see this?](https://bitcoin.stackexchange.com/questions/52575/how-did-blockr-io-see-this)

> **Comments:**
> **username_1**: I am listening to the network in a completely different way to you and seeing the same thing! I'm not saying I am correct but, if you can prove this answer wrong that would be interesting! I would wonder what voodoo magic is going on here!  

---

