On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

If a node is using priority queued rate limiting for its relaying then

it might "accept" a transaction from you, but have it fall out of its
memory pool (due to higher priority txn arriving, or getting
restarted, etc.) before it ever gets a chance to send it on to any
other peers.

That's a good point, however, I would hope that this fairly trivial race condition can be resolved. There's no requirement that a transaction be placed into a buffer from which it can be removed before relaying. After relaying - sure. But the gap of a few seconds between that shouldn't cause any issues to eliminate.

I believe Gavin's smartfees branch adds mempool persistence to disk, so restarting nodes won't clear the mempool in future. Or at least that's a part of the longer term plan once mempool limiting is done.

Finding out that it rejected is still useful information, but even
assuming all nodes are honest and well behaved I don't think you could
count on its absence to be sure of forwarding.

I think measuring propagation will be a part of bitcoin wallets for the forseeable future, although if all nodes reject that allows for a more responsive and more helpful UI than just waiting for some arbitrary timeout to elapse.