rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2013-10-27 📝 Original message: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. 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. On Sun, Oct 27, 2013 at 3:39 PM, Luke-Jr <luke at dashjr.org> wrote: > On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote: > > Currently bitcoinj gets a small but steady stream of bug reports of the > form > > "my transaction did not propagate". It's flaky because the library picks > one > > peer to send the transaction to, and then watches it propagate across the > > network. But if that selected peer refuses the tx for whatever reason, > that > > propagation never comes, and there's currently no timeout to make it > retry > > with a different node. > > Sounds like the real bug is "BitcoinJ relies on good/servant behaviour from > other nodes". Don't assume your random node isn't hostile. Handling a peer > that doesn't relay your transaction for any reason (including if they lie > to > you about having done so) should be expected behaviour. > > Luke > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131027/dfd261cc/attachment.html>