Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45F7644CC for ; Wed, 6 Mar 2019 17:04:32 +0000 (UTC) X-Greylist: delayed 00:15:03 by SQLgrey-1.7.6 Received: from blaine.gmane.org (unknown [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A37F5E2 for ; Wed, 6 Mar 2019 17:04:31 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h1ZjR-000gc8-ER for bitcoin-dev@lists.linuxfoundation.org; Wed, 06 Mar 2019 17:49:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Wed, 6 Mar 2019 17:49:20 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Openpgp: preference=signencrypt Autocrypt: addr=andreas@schildbach.de; keydata= xsDiBD/S9DARBACgg0IF3cCFaNXbQtCAZBpiZRawQAfsfL87sHhy1xq3UwR4RmQKsWjtZQ9C 7kSDTkzzn7Sqg+YtXgiJdGeYinSMy+6mBKQjtrIKLikbjB1ORTfA29m7m7VTBY9X3Cvmpm0+ 0mWvrQ9hSpq8adXitY4Z+/VB/1YSo77RakfNr3sQOwCgzrXH37AlAu307IgOOFnI1y78Y4cD /29gtaY3/u8ThFI/mXBOHnfXaIVGLYKtlf2Lyj2JnixhhzxEpuDJ0lkcyNQ0N7Ky8ohJS3tG ShwHjsQNtqK2V1DomsUnDI/W4hJNCSd0zfIoQgHvE1RbOyOpz4F+CNw8uQcxwE5FmwRtk6xa zJsiMVKLFhKr6LnMoVaNi8mZZFKzA/9HcXAse5epfrZD1tt7dHr58+egIA0OkoQ8oUgqCgN1 4qmUxQoWTdmvet0E+XaHcowr1fXu79uQ2zuvHSk/S4mjP6uT+XOxENVcKRUtyEBtSzFDyyCj 853KrBQSppCgxS8loHj1g1YIKqu97kGVtfmHM9L9TPVA1opuYOcJh7iJ9s0qQW5kcmVhcyBT Y2hpbGRiYWNoIDxhbmRyZWFzQHNjaGlsZGJhY2guZGU+wl4EExECAB4FAj/S9DACGwMGCwkI BwMCAxUCAwMWAgECHgECF4AACgkQymYr4YuHemD4NACePnpSANmR2vrZVv+BteOva6gzOJ0A nioa6JoKCYx3jQOIqoBGcBUkc8q1zsFNBD/S9DgQCACctel4AnL7nuh+Uv+IBz0GMvu6Ewdn sVCOLf54neIxuaW4BC5RYAdS6Tkp3hxv+ZfA0Uv6X3nz4tOsVHD50+CCq51pRlnbUwcWcn9e nynJyddTjei+JmJrdOJOAzWa/al8YagjQSZqgD6mmPUy/a201Bh0L2zbLmxQMFg+PPB81j4y UmSXmhYzg/+SonZ3lr9pJNtoZszg95NDyYBceiF5RSw4Qusi+C5/W3nIKzuaIKZijE9Dvo6D W6ggbB/gSxDTSjvrnvvXeG1SdlKLeFvsJ9y/0ro3EP01RRVJvA5RaM5W2MRbwGuSRcSw8B74 6ijEOqSh0IYLXoHdV7Vj4Qt/AAMFB/9ZcgxVGvs2ob6MCTVdPLlVKRKDn7RjZiDE6hRa/jp7 ewdstjjc22DU/jCz16IX75B/sr1cDJqbChONFdljjQNWe2cTFXSazUjsyZa35+KvehDi7cAU +vCYmisMpkPM41hR6HYqjadDp6gOVJTnHPcJ6EPdgUQTsNQH3dCTD68b5WwzBEBNLdwyDGLK McExzaOClwwSeHBmnj72O7Chdhn/M/2+fpTUPqhp/0sflVyR/ILyc/KEp85pwani2dXuZ02i gSaSIBwQJOVrjsUTwp2Wxdmywt13/cGGVlsGLe8lY0Kv6G43/eip+42OfIVhxRgARRtJ5KjK chTLwfl3tbgawkkEGBECAAkFAj/S9DgCGwwACgkQymYr4YuHemAWjACgtRlmiISVlCf7/mum klJfLM6wKIMAnA2uS1BS4d7GJkQp09ViaWmUUsMc In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, RDNS_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 07 Mar 2019 10:14:09 +0000 Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 17:04:32 -0000 Reject messages cannot be replaced for debugging user problems. At least unless you plan to make RPC or bitcoind logfiles available via the P2P protocol (both probably not a good idea). The typical case is, I get mailed a wallet logfile with reject messages and that's all I have. I cannot access the bitcoind logfile(s) of the node(s) that generated the reject message in the first place. Nor can I access their RPC interface. I strongly suggest re-enabling reject messages by default before 0.18. On 06/03/2019 01.53, Marco Falke via bitcoin-dev 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=`) to a stream (`-printtoconsole`) or to a file > (`-debuglogfile=`). > > * 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 >