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
I’ve solved the same problem in a different way.
1) Submit a transaction2) 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 errors4) Wait for our txid to be submitted back to us through the mempool, if we get it notify success and delete all pending error events5) 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 <bitcoin-dev@lists.linuxfoundation.org> 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