<oembed><type>rich</type><version>1.0</version><author_name>npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7</author_name><author_url>https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2019-03-06&#xA;📝 Original message:Reject messages cannot be replaced for debugging user problems. At least&#xA;unless you plan to make RPC or bitcoind logfiles available via the P2P&#xA;protocol (both probably not a good idea).&#xA;&#xA;The typical case is, I get mailed a wallet logfile with reject messages&#xA;and that&#39;s all I have. I cannot access the bitcoind logfile(s) of the&#xA;node(s) that generated the reject message in the first place. Nor can I&#xA;access their RPC interface.&#xA;&#xA;I strongly suggest re-enabling reject messages by default before 0.18.&#xA;&#xA;&#xA;On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:&#xA;&gt; Bitcoin Core may send &#34;reject&#34; messages as response to &#34;tx&#34;, &#34;block&#34; or&#xA;&gt; &#34;version&#34; messages from a network peer when the message could not be accepted.&#xA;&gt; &#xA;&gt; This feature is toggled by the `-enablebip61` command line option and has been&#xA;&gt; disabled by default since Bitcoin Core version 0.18.0 (not yet released as of&#xA;&gt; time of writing). Nodes on the network can not generally be trusted to send&#xA;&gt; valid (&#34;reject&#34;) messages, so this should only ever be used when connected to a&#xA;&gt; trusted node. At this time, I am not aware of any software that requires this&#xA;&gt; feature, and I would like to remove if from Bitcoin Core to make the codebase&#xA;&gt; slimmer, easier to understand and maintain. Let us know if your application&#xA;&gt; relies on this feature and you can not use any of the recommended alternatives:&#xA;&gt; &#xA;&gt; * Testing or debugging of implementations of the Bitcoin P2P network protocol&#xA;&gt;   should be done by inspecting the log messages that are produced by a recent&#xA;&gt;   version of Bitcoin Core. Bitcoin Core logs debug messages&#xA;&gt;   (`-debug=&lt;category&gt;`) to a stream (`-printtoconsole`) or to a file&#xA;&gt;   (`-debuglogfile=&lt;debug.log&gt;`).&#xA;&gt; &#xA;&gt; * Testing the validity of a block can be achieved by specific RPCs:&#xA;&gt;   - `submitblock`&#xA;&gt;   - `getblocktemplate` with `&#39;mode&#39;` set to `&#39;proposal&#39;` for blocks with&#xA;&gt;     potentially invalid POW&#xA;&gt; &#xA;&gt; * Testing the validity of a transaction can be achieved by specific RPCs:&#xA;&gt;   - `sendrawtransaction`&#xA;&gt;   - `testmempoolaccept`&#xA;&gt; &#xA;&gt; * Wallets should not use the absence of &#34;reject&#34; messages to indicate a&#xA;&gt;   transaction has propagated the network, nor should wallets use &#34;reject&#34;&#xA;&gt;   messages to set transaction fees. Wallets should rather use fee estimation&#xA;&gt;   to determine transaction fees and set replace-by-fee if desired. Thus, they&#xA;&gt;   could wait until the transaction has confirmed (taking into account the fee&#xA;&gt;   target they set (compare the RPC `estimatesmartfee`)) or listen for the&#xA;&gt;   transaction announcement by other network peers to check for propagation.&#xA;&gt; &#xA;&gt; I propose to remove &#34;reject&#34; messages from Bitcoin Core 0.19.0 unless there are&#xA;&gt; valid concerns about its removal.&#xA;&gt; &#xA;&gt; Marco&#xA;&gt;</html></oembed>