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 615ADAF0 for ; Fri, 18 Oct 2019 20:53:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 00ED7821 for ; Fri, 18 Oct 2019 20:53:36 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id 60so6118700otu.0 for ; Fri, 18 Oct 2019 13:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnewbery-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VtA7JtFWaA14yl4jXBfEuEAy5sNwUbVBVNM9RWb33Zg=; b=LQ6K2tNwqdEnGFEV74csD2ByfD+YS+RHw2c68nXcxV+GRE5e0fgT9q1rEEkDw2h4UM 7ljGndZN7hPJEIXtCa6C8bElr/omsuWyh5jS/aMl9XQk+i1r9UJxbL6gE+AS7jvAKC/8 bLrfkhScS0VaHIeEdkZFFbaelPRoEboJAHaAv4m+N37y//M5dsWfIZhKSokQ9GIoUXJA tikE6BQi8iIZCl1Hf2YFKVAJDA/cVFglCtzy5AQrcwiKR/+G4aRNXjE4P/TkdBbzsnzW /yS2OVCh7aPDylSw7xnEQjPcasBYCktHZaYDog62HmZD4XHGVd1HMT3/398M41P2HXpz 4QdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VtA7JtFWaA14yl4jXBfEuEAy5sNwUbVBVNM9RWb33Zg=; b=WRk2dQg1MiGLo0nltII9/dHAc9Evfkqv0qxkV0wR34Xuy049+MffoAvhw5BXTcjMKs vw1vawFGl0kaUHnHgmGkbwhm8ORP7OK5Lzgd5ivUCLFsKEdBTS0bkLoqMj/IRVQhQuiu teyE2nqb8wY1VF5QDscb0TLac1147Sf+yOOJPnn65XtId78shCEjaNx4EBwlMVhjG9+U KMkgcKdax8COoz027CzCJjodOwjWU2lpZrEVtMYIL96mtSL7YRUegLHzuzazjC9XSJn2 vfyhR/8jnoWbT2iFNAOYQEG6WgWFM4+QsPUt34ludk0uWRc6NamcZSCuyHCXAJQ+ZNf6 HmfA== X-Gm-Message-State: APjAAAVMKI2u65d6zF7fBq0mHzHyoZia1v3jYCOoEg/jZBhBNZuthGL1 1Io7EWyGgOUuKct+AUZ9HykFhEd/hIM= X-Google-Smtp-Source: APXvYqyuOPe8sTHebs80ZlBUlHTIwgRQZycpZy7cpRA33CRTiHO24qco5uDOAUTsaB+xJq8n9TBEeA== X-Received: by 2002:a05:6830:22e6:: with SMTP id t6mr9169381otc.65.1571432015673; Fri, 18 Oct 2019 13:53:35 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com. [209.85.210.47]) by smtp.gmail.com with ESMTPSA id y11sm1687019oih.18.2019.10.18.13.53.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Oct 2019 13:53:34 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id g13so6082036otp.8 for ; Fri, 18 Oct 2019 13:53:34 -0700 (PDT) X-Received: by 2002:a9d:37a1:: with SMTP id x30mr9608771otb.49.1571432013831; Fri, 18 Oct 2019 13:53:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Newbery Date: Fri, 18 Oct 2019 16:53:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Marco Falke via bitcoin-dev Content-Type: multipart/alternative; boundary="000000000000f9243e059535864b" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 18 Oct 2019 21:32:45 +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: Fri, 18 Oct 2019 20:53:40 -0000 --000000000000f9243e059535864b Content-Type: text/plain; charset="UTF-8" > 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 < > bitcoin-dev@lists.linuxfoundation.org> 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 >> > --000000000000f9243e059535864b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Is 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 <john@joh= nnewbery.com> wrote:
Following discussion on this mailing list= , support for BIP 61 REJECT messages was not removed from Bitcoin Core in V= 0.19. The behaviour in that upcoming release is that REJECT messages are di= sabled by default and can be enabled using the `-enablebip61` command line = option.

Support for REJECT messages will be removed entirely in Bitc= oin 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 severa= l months. https://bitnodes.earn.com/dashboard/?days=3D365 shows that= although v0.18 was released in May 2019, there are still several hundred r= eachable nodes on V0.17, V0.16, V0.15 and earlier software. Software that c= urrently use REJECT messages from public nodes for troubleshooting issues t= herefore 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 <bitcoin-dev@lists.linuxfoundati= on.org> wrote:
Bitcoin Core may send "reject" messages as response to &quo= t;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 b= een
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 th= is
feature, and I would like to remove if from Bitcoin Core to make the codeba= se
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 alternati= ves:

* Testing or debugging of implementations of the Bitcoin P2P network protoc= ol
=C2=A0 should be done by inspecting the log messages that are produced by a= recent
=C2=A0 version of Bitcoin Core. Bitcoin Core logs debug messages
=C2=A0 (`-debug=3D<category>`) to a stream (`-printtoconsole`) or to = a file
=C2=A0 (`-debuglogfile=3D<debug.log>`).

* Testing the validity of a block can be achieved by specific RPCs:
=C2=A0 - `submitblock`
=C2=A0 - `getblocktemplate` with `'mode'` set to `'proposal'= ;` for blocks with
=C2=A0 =C2=A0 potentially invalid POW

* Testing the validity of a transaction can be achieved by specific RPCs: =C2=A0 - `sendrawtransaction`
=C2=A0 - `testmempoolaccept`

* Wallets should not use the absence of "reject" messages to indi= cate a
=C2=A0 transaction has propagated the network, nor should wallets use "= ;reject"
=C2=A0 messages to set transaction fees. Wallets should rather use fee esti= mation
=C2=A0 to determine transaction fees and set replace-by-fee if desired. Thu= s, they
=C2=A0 could wait until the transaction has confirmed (taking into account = the fee
=C2=A0 target they set (compare the RPC `estimatesmartfee`)) or listen for = the
=C2=A0 transaction announcement by other network peers to check for propaga= tion.

I propose to remove "reject" messages from Bitcoin Core 0.19.0 un= less there are
valid concerns about its removal.

Marco
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000f9243e059535864b--