From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B2041BA0 for ; Mon, 21 Oct 2019 08:44:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from blaine.gmane.org (195-159-176-226.customer.powertech.no [195.159.176.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90D768B2 for ; Mon, 21 Oct 2019 08:44:27 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iMTIe-0014fk-1f for bitcoin-dev@lists.linuxfoundation.org; Mon, 21 Oct 2019 10:44:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-dev@lists.linuxfoundation.org From: Andreas Schildbach Date: Mon, 21 Oct 2019 10:44:16 +0200 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, KHOP_HELO_FCRDNS,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Mon, 21 Oct 2019 08:44:28 -0000 I guess then the best way to discover nodes that have reject messages enabled is connecting/disconnecting to random nodes and send them invalid transactions and keep the ones which reply with a reject message. On 18/10/2019 22.53, John Newbery via bitcoin-dev wrote: >> 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 > 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 > > 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 > _______________________________________________ > 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 >