Apparently I don't have the same experience than others here, what I encountered is no reject message received for wrong txs, but from what I understand here it's not unusual to receive reject message for valid txs, then I don't see how it can be really helpful/relied, given also that the reject messages are unclear and even can be misleading As it was written already I found it useful only for debugging purposes, at least it can give some kind of ideas about what happened, bitcoin-transactions is implementing the bitcoin protocol but does not act as a node and does not pretend to fake a node behavior waiting for example to get the tx back, is the method of sending a getdata for a given tx to see if it was accepted by a node wrong ? It can't guarantee 100% that it was successful and will propagate but I see that you are doing completely different things Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit : > I’ve solved the same problem in a different way. > > 1) Submit a transaction > 2) Collect all reject messages (that have matching txid in the reject > data) > 3) Wait 16 seconds after first error message received (chosen > semirandomly from trial and error) before processing errors > 4) Wait for our txid to be submitted back to us through the mempool, > if we get it notify success and delete all pending error events > 5) Signal failure with the given reject code if present (after the 16 > seconds have elapsed) > 6) If no error or success after 20 seconds, signal timeout failure > > This works fairly well in testing. Newer transaction types seem to > generate reject codes 100% of the time (from at least one node when > sending to 4 nodes) so this culling / time delay approach is > essentially required. > > On a related note: One issue is that RBF attempts with too small a fee > and accidental double spends (with enough fee for 1 tx but not a RBF) > both generate the same reject code: not enough fee. > > A new reject code for RBF based too small of fee would definitely make > for a better user experience as I’ve seen this exact problem create > confusion for users. > > Removing reject codes would make for a much worse user experience. > “Your tx failed and we have no idea why” would be the only message and > it would require waiting for a full timeout. > > On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev > > wrote: > > > I'd like to better understand this, but it would be easier to just > > read the code than ask a bunch of questions. I tried looking for the > > handling of reject messages in Android  Bitcoin Wallet and BitcoinJ > > and didn't really find and handling other than logging exceptions. > > Would you mind giving me a couple pointers to where in the code > > they're handled? > > https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms