Following discussion on this mailing list, support for BIP 61 REJECT messages was not removed from Bitcoin Core in V0.19. The behaviour in that upcoming release is that REJECT messages are disabled by default and can be enabled using the `-enablebip61` command line option.

Support for REJECT messages will be removed entirely in Bitcoin Core V0.20, expected for release in mid 2020. The PR to remove support was merged into Bitcoin Core's master branch this week.

Adoption of new Bitcoin Core versions across reachable nodes generally takes several months. https://bitnodes.earn.com/dashboard/?days=365 shows that although v0.18 was released in May 2019, there are still several hundred reachable nodes on V0.17, V0.16, V0.15 and earlier software. Software that currently use REJECT messages from public nodes for troubleshooting issues therefore have plenty of time to transition to one of the methods listed by Marco in the email above.

John

On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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