On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell 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.