<p>There are no timeouts, and a valid transaction can be mined at any time.</p>

<p>The only thing that can ensure a particular transaction won't get mined in the current block chain is to make it invalid.  The only practical way to do that is to create a confirmed double spend---another transaction that spends one of the same inputs as the transaction you don't want mined.  Once that double spend is confirmed, your original transaction can't be added to a block in the same block chain as the confirmed double spend.</p>

CC BY-SA 3.0
2015-01-18T15:08:59.097Z
It's straightforward because you're making the assumption that the peer did receive the transaction, whereas after you publish a transaction you may get no answer at all from the peer. All scenarios are feasible: 1) the peer added the tx to the mempool, 2) the peer rejected the tx as invalid, 3) the peer didn't receive any data due to a networking problem. How am I supposed to find out?
keeshux
CC BY-SA 3.0
2015-01-18T15:38:20.213Z
Barring an omniscient view of the network, you can't know what happened to your transaction.  If you still want the transaction to be valid, rebroadcast it.  If you don't want it to be valid, double spend it.  Any other action introduces security risks, because your original transaction is still valid even if peers don't seem to have received it or claimed it was invalid.
David A. Harding
CC BY-SA 3.0
2015-01-18T15:47:22.333Z
What I'm saying here is that many network protocols (say HTTP) work in a way that the sender has some ACK telling that its message has been at least delivered. After all, if I connect to multiple peers I expect to receive the relayed 'TX' from the other peers, so why wouldn't the relaying peer answer with an ACK message in the first place? Basically I wonder what's the reason behind this choice.
keeshux
CC BY-SA 3.0
2015-01-18T16:00:54.713Z
The Bitcoin P2P protocol uses TCP, which will generate an error if delivery of a packet was unsuccessful.  Satoshi did evidentially realize that the TCP checksum was a bit insufficient at preventing packet mangling because he added checksums to Bitcoin packet headers in protocol version 209.  Gavin realized that it might be nice to tell peers that their packets were mangled in transit, so  for this reason (and other reasons) he added the `reject` message in protocol version 70002.
David A. Harding
CC BY-SA 3.0
2015-01-18T16:38:01.440Z
I really appreciate the insight, still it doesn't answer my question. Why "notify rejection" but "silently accept validity"? What's the point of forcing a client to connect to another peer (seems the only way) to learn that its transaction was added to the mempool? AFAIK, "no answer" may mean "transaction is valid" as well as "transaction was never received".
keeshux
CC BY-SA 3.0
2015-01-18T16:44:21.297Z
TCP isn't silent.  Read the Wikipedia article: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission
David A. Harding
CC BY-SA 3.0
2015-01-15T02:24:38.430Z
2015-01-15T02:24:38.430Z
David A. Harding
<p>If the nodes I connect to don't support the BIP 61 <code>reject</code> message, how do I know that my transaction was eventually rejected by the network (e.g. due to my bugs)? Is there any timeout or whatever after which it's reasonable to assume that my peers will never relay the transaction?</p>

<transactions><raw-transaction><peers>
How to detect a rejected transaction?
keeshux
# How to detect a rejected transaction?

(Asked by: username_0 on 2014-08-30)

If the nodes I connect to don't support the BIP 61 `reject` message, how do I know that my transaction was eventually rejected by the network (e.g. due to my bugs)? Is there any timeout or whatever after which it's reasonable to assume that my peers will never relay the transaction?

**Tags:** transactions, raw-transaction, peers


---

## 1 answers

### Answer by username_1 on 2015-01-15. Score: 1

There are no timeouts, and a valid transaction can be mined at any time.

The only thing that can ensure a particular transaction won't get mined in the current block chain is to make it invalid. The only practical way to do that is to create a confirmed double spend---another transaction that spends one of the same inputs as the transaction you don't want mined. Once that double spend is confirmed, your original transaction can't be added to a block in the same block chain as the confirmed double spend.

> **Comments:**
> **username_0**: It's straightforward because you're making the assumption that the peer did receive the transaction, whereas after you publish a transaction you may get no answer at all from the peer. All scenarios are feasible: 1) the peer added the tx to the mempool, 2) the peer rejected the tx as invalid, 3) the peer didn't receive any data due to a networking problem. How am I supposed to find out?  
> **username_1**: Barring an omniscient view of the network, you can't know what happened to your transaction.  If you still want the transaction to be valid, rebroadcast it.  If you don't want it to be valid, double spend it.  Any other action introduces security risks, because your original transaction is still valid even if peers don't seem to have received it or claimed it was invalid.  
> **username_0**: What I'm saying here is that many network protocols (say HTTP) work in a way that the sender has some ACK telling that its message has been at least delivered. After all, if I connect to multiple peers I expect to receive the relayed 'TX' from the other peers, so why wouldn't the relaying peer answer with an ACK message in the first place? Basically I wonder what's the reason behind this choice.  
> **username_1**: The Bitcoin P2P protocol uses TCP, which will generate an error if delivery of a packet was unsuccessful.  Satoshi did evidentially realize that the TCP checksum was a bit insufficient at preventing packet mangling because he added checksums to Bitcoin packet headers in protocol version 209.  Gavin realized that it might be nice to tell peers that their packets were mangled in transit, so  for this reason (and other reasons) he added the `reject` message in protocol version 70002.  
> **username_0**: I really appreciate the insight, still it doesn't answer my question. Why "notify rejection" but "silently accept validity"? What's the point of forcing a client to connect to another peer (seems the only way) to learn that its transaction was added to the mempool? AFAIK, "no answer" may mean "transaction is valid" as well as "transaction was never received".  
> **username_1**: TCP isn't silent.  Read the Wikipedia article: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission  

---

