Author: Andreas Schildbach 2019-03-07 17:58:01
Published on: 2019-03-07T17:58:01+00:00
Bitcoin Core may send "reject" messages as a response to "tx", "block" or "version" messages from a network peer when the message cannot 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 cannot generally be trusted to send valid ("reject") messages, so this should only ever be used when connected to a trusted node. At this time, there is no software that requires this feature, and developers are recommended to use alternatives for testing, debugging, and validating transactions and blocks.Reject messages are an indication that the transaction isn't going to confirm, and they are useful in distinguishing cases such as not enough fee, UTXO already spent, and invalid signature. The first two happen even in the ideal case, as fees are impossible to predict, and unintentional double spends happen because users clone their wallet state. While the last one theoretically wouldn't be necessary if you produced your software bug-free to begin with, this just isn't how software development works. Developers need any indication they can get.A user asked about what kind of reject messages their wallet users are getting, and Andreas Schildbach via bitcoin-dev responded that reject messages cannot be replaced for debugging user problems. The typical case is receiving a wallet logfile with reject messages, which is all they have, as they cannot access the bitcoind logfile(s) of the node(s) that generated the reject message in the first place. Nor can they access their RPC interface. Schildbach strongly suggests re-enabling reject messages by default before 0.18. Marco Falke via bitcoin-dev proposed to remove "reject" messages from Bitcoin Core 0.19.0 unless there are valid concerns about its removal, and he listed alternatives for testing, validating, and debugging transactions and blocks. 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.
Updated on: 2023-06-13T17:17:52.805028+00:00