<div dir="ltr">These nodes are much more likely to just be broken than malicious, but without any way to diagnose why they are dropping a transaction it&#39;s hard to find out what&#39;s really going on.<div><br></div><div>
Anyway, yes, I need to spend time adding timeouts and all kinds of other things, although of course if the transactions are being rejected due to a change in network rules that won&#39;t help either - if the nodes you&#39;re connected to are silently eating your transaction, there&#39;s no sane UI that can result from that without more explicit error handling.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Oct 27, 2013 at 3:39 PM, Luke-Jr <span dir="ltr">&lt;<a href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:<br>
&gt; Currently bitcoinj gets a small but steady stream of bug reports of the form<br>
&gt; &quot;my transaction did not propagate&quot;. It&#39;s flaky because the library picks one<br>
&gt; peer to send the transaction to, and then watches it propagate across the<br>
&gt; network. But if that selected peer refuses the tx for whatever reason, that<br>
&gt; propagation never comes, and there&#39;s currently no timeout to make it retry<br>
&gt; with a different node.<br>
<br>
</div>Sounds like the real bug is &quot;BitcoinJ relies on good/servant behaviour from<br>
other nodes&quot;. Don&#39;t assume your random node isn&#39;t hostile. Handling a peer<br>
that doesn&#39;t relay your transaction for any reason (including if they lie to<br>
you about having done so) should be expected behaviour.<br>
<span class="HOEnZb"><font color="#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>