<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's hard to find out what'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't help either - if the nodes you're connected to are silently eating your transaction, there'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"><<a href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.org</a>></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>
> Currently bitcoinj gets a small but steady stream of bug reports of the form<br>
> "my transaction did not propagate". It's flaky because the library picks one<br>
> peer to send the transaction to, and then watches it propagate across the<br>
> network. But if that selected peer refuses the tx for whatever reason, that<br>
> propagation never comes, and there's currently no timeout to make it retry<br>
> with a different node.<br>
<br>
</div>Sounds like the real bug is "BitcoinJ relies on good/servant behaviour from<br>
other nodes". Don't assume your random node isn't hostile. Handling a peer<br>
that doesn'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>