3
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?
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.
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 – 2015-01-18T15:08:59.097
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 – 2015-01-18T15:38:20.213
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 – 2015-01-18T15:47:22.333
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
rejectmessage in protocol version 70002. – David A. Harding – 2015-01-18T16:00:54.713I 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 – 2015-01-18T16:38:01.440
TCP isn't silent. Read the Wikipedia article: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission
– David A. Harding – 2015-01-18T16:44:21.297