<div dir="ltr">On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell <span dir="ltr">&lt;<a href="mailto:gmaxwell@gmail.com" target="_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">If a node is using priority queued rate limiting for its relaying then</span><br>
</div>
it might &quot;accept&quot; a transaction from you, but have it fall out of its<br>
memory pool (due to higher priority txn arriving, or getting<br>
restarted, etc.) before it ever gets a chance to send it on to any<br>
other peers.<br></blockquote><div><br></div><div>That&#39;s a good point, however, I would hope that this fairly trivial race condition can be resolved. There&#39;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&#39;t cause any issues to eliminate.</div>
<div><br></div><div>I believe Gavin&#39;s smartfees branch adds mempool persistence to disk, so restarting nodes won&#39;t clear the mempool in future. Or at least that&#39;s a part of the longer term plan once mempool limiting is done.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Finding out that it rejected is still useful information, but even<br>
assuming all nodes are honest and well behaved I don&#39;t think you could<br>
count on its absence to be sure of forwarding.<br>
</blockquote></div><br></div><div class="gmail_extra">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.</div>
</div>