2
1
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?
0
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
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 and How did blockr.io see this?
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 – 2017-04-04T20:45:38.137
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 – 2017-04-04T17:37:19.000
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 – 2017-04-04T17:39:19.083
i never see the altered utx broadcasted – Ben Muircroft – 2017-04-04T17:40:56.800
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 – 2017-04-04T17:41:45.013
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 – 2017-04-04T17:44:49.143
look at this dude! http://bitcoin.stackexchange.com/a/52576/14316 propper interesting (about us not seeing YYY broadcasted!)
– Ben Muircroft – 2017-04-04T22:35:50.997