<p>With Bitcoin-Qt/bitcoind there there is no callback or other real-time notification that a transaction that had previously been a valid 0/unconfirmed is not a transaction that will not confirm due to there being another confirmed transaction for the same unspent transaction output (UTXO).</p>

<p>When a new block is found, each transaction can be inspected (using Raw transactions) to determine the INPUT(s).   If the input was already used by a previously seen transaction, then the spend from the block would cause the earlier transaction to be an invalid double spend and it can be purged.</p>

<p>The Bitcoin-Qt/bitcoind client will no longer display the 0/unconfirmed transaction for a payment received that becomes invalid after a double spend from a new block arrives.</p>

CC BY-SA 3.0
2013-04-13T06:41:06.970Z
The app already keeps track of transactions in its own database, so I'll just add some code to recheck any unconfirmed (<6 confirms) transactions to see if they still exist, and warn if they disappear.
dkisselev
CC BY-SA 3.0
2013-04-13T05:49:11.637Z
2013-04-13T05:49:11.637Z
Stephen Gornick
<p>I'm working on writing a wrapper for the standard bitcoin client. I'll be communicating with it via the JSON-RPC API and I'm just wondering if anyone has any experience with this;
this app is mostly geared to receive BTC, not send.</p>

<p>How does the client react when it sees an incoming transaction from an address of x BTC, but it is later determined by the network that that transaction was invalid (probably due to a double-spend by someone sending BTC to an address, then immediately sending the same BTC to another address but from a far away play so the lag allows both to go through. In this case I'm talking about transactions before a block is mined)</p>

<p>Does the transaction just disappear off the network and away from the bitcoind interface/API or is that recorded somewhere? (In the confirms result in the API?)</p>

<p>I want my app to be able to keep track of any instances of this happening and notify the end user.</p>

<p>Thanks.</p>

CC BY-SA 3.0
2013-04-12T23:00:35.650Z
When you say standard bitcoin client what do you exactly do you mean? I know with the mtgox api, if an order fails an error object is returned and you can catch it and do what you will with it.
Loourr
<transactions><block><api>
How does the reference bitcoin wallet/client handle rejected transactions? (in the API)
dkisselev
# How does the reference bitcoin wallet/client handle rejected transactions? (in the API)

(Asked by: username_0 on 2013-04-12)

I'm working on writing a wrapper for the standard bitcoin client. I'll be communicating with it via the JSON-RPC API and I'm just wondering if anyone has any experience with this;
this app is mostly geared to receive BTC, not send.

How does the client react when it sees an incoming transaction from an address of x BTC, but it is later determined by the network that that transaction was invalid (probably due to a double-spend by someone sending BTC to an address, then immediately sending the same BTC to another address but from a far away play so the lag allows both to go through. In this case I'm talking about transactions before a block is mined)

Does the transaction just disappear off the network and away from the bitcoind interface/API or is that recorded somewhere? (In the confirms result in the API?)

I want my app to be able to keep track of any instances of this happening and notify the end user.

Thanks.

**Tags:** transactions, block, api

> **Comments:**
> **username_1**: When you say standard bitcoin client what do you exactly do you mean? I know with the mtgox api, if an order fails an error object is returned and you can catch it and do what you will with it.  

---

## 1 answers

### Answer by username_2 on 2013-04-13. Score: 2 | Accepted answer

With Bitcoin-Qt/bitcoind there there is no callback or other real-time notification that a transaction that had previously been a valid 0/unconfirmed is not a transaction that will not confirm due to there being another confirmed transaction for the same unspent transaction output (UTXO).

When a new block is found, each transaction can be inspected (using Raw transactions) to determine the INPUT(s). If the input was already used by a previously seen transaction, then the spend from the block would cause the earlier transaction to be an invalid double spend and it can be purged.

The Bitcoin-Qt/bitcoind client will no longer display the 0/unconfirmed transaction for a payment received that becomes invalid after a double spend from a new block arrives.

> **Comments:**
> **username_0**: The app already keeps track of transactions in its own database, so I'll just add some code to recheck any unconfirmed (<6 confirms) transactions to see if they still exist, and warn if they disappear.  

---

