> Is there a NODE_* bit we can use to pick peers that support this (useful!) feature?
No. BIP 61 has no mechanism for advertising that a node will send REJECT messages. On Wed, Oct 16, 2019 at 12:43 PM John Newbery <j...@johnnewbery.com> wrote: > 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 >> >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
