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