Bitcoin-transactions did use this "feature", but does not rely on it any longer since I observed some strange behavior sometimes (no reject message for bad tx, with suprnova for example as far as I remember), then it doublechecks using getdata to see if the tx is in mempool
Indeed you can't trust what a node tells you with or without reject (idem for getdata but more difficult to fake and better than nothing) Then I don't see any problem to remove it, taking into account also that the error message is too vague to be really helpful https://github.com/bitcoin/bitcoin/issues/11891 Le 06/03/2019 à 01:53, Marco Falke via bitcoin-dev a écrit : > Bitcoin Core may send "reject" messages as response to "tx", "block" or > "version" messages from a network peer when the message could not be accepted. > > This feature is toggled by the `-enablebip61` command line option and has been > disabled by default since Bitcoin Core version 0.18.0 (not yet released as of > time of writing). Nodes on the network can not generally be trusted to send > valid ("reject") messages, so this should only ever be used when connected to > a > trusted node. At this time, I am not aware of any software that requires this > feature, and I would like to remove if from Bitcoin Core to make the codebase > slimmer, easier to understand and maintain. Let us know if your application > relies on this feature and you can not use any of the recommended > alternatives: > > * Testing or debugging of implementations of the Bitcoin P2P network protocol > should be done by inspecting the log messages that are produced by a recent > version of Bitcoin Core. Bitcoin Core logs debug messages > (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file > (`-debuglogfile=<debug.log>`). > > * Testing the validity of a block can be achieved by specific RPCs: > - `submitblock` > - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with > potentially invalid POW > > * Testing the validity of a transaction can be achieved by specific RPCs: > - `sendrawtransaction` > - `testmempoolaccept` > > * Wallets should not use the absence of "reject" messages to indicate a > transaction has propagated the network, nor should wallets use "reject" > messages to set transaction fees. Wallets should rather use fee estimation > to determine transaction fees and set replace-by-fee if desired. Thus, they > could wait until the transaction has confirmed (taking into account the fee > target they set (compare the RPC `estimatesmartfee`)) or listen for the > transaction announcement by other network peers to check for propagation. > > I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there > are > valid concerns about its removal. > > Marco > _______________________________________________ > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev