Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 214B938A0 for ; Wed, 6 Mar 2019 04:00:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 34DD278C for ; Wed, 6 Mar 2019 04:00:49 +0000 (UTC) Received: by mail-wr1-f53.google.com with SMTP id i12so11742443wrw.0 for ; Tue, 05 Mar 2019 20:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4cKdAwqmtVCXnsg6GmtMkfEjwbzOQuaKDX2ffVfFWSk=; b=cijFIgCzWGjcFUjhulDUs0rHfVfvbhkhQ32tsiXFs4ahrjqwTlTUD4w0wlFX1t6oKP koFh14r+FYDCbgqOk+s7lxg4S4s7+kDgTEpgiMVJ8zNvEybwdRkwjdgQJRs2SiqJpnnZ B2b2g8L/ITM/HsBiErvTyFBRIMtjqUUPyKDuiijilmmQnKzADtH4dugGZFO1qcLqBsmn aqGno3xeMzT5+KNuX5rI3lmm8tc6WElXRD4Vhq1icJ6mKr/r8y0cG3edXR/ePk+p0ucv 7tJwOtpOeQRSVtGZQE2E/J3rgZobvyJiViBN8PHJkJv4YGBZoFGPJwcq9ukIpWSVUJCC /b+A== 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=4cKdAwqmtVCXnsg6GmtMkfEjwbzOQuaKDX2ffVfFWSk=; b=lq2P32oMsTCpSYTbTCJjdsGhaoVp7elY1Q75JXSexs7vGKoDZWV8DVTEaO8K+CYpgj 3yQ5qO9hnanEyh5jJG8uhJu4QtSOry1U95bKdKK5sDdh3s+5Dr0e2aE4UI54wcou01rR 2xYqIbfd8QxutlzFWHgz0l0lAuj/cKqklHN+82HU6WcJ7D4yzj474gy4crHoQjRqoPoc 3vej9qgXzjzirWVWSU+pRVRvhG7oCgvGUdqs7cMWrWf8mMTUfNPh5rsvh+oFCGFCEskL YrlewrB+jECAKFoKSQz2Z/EUweIJXMuVF4FXP9/Way53uX3W4eeus8xRM+U8rpWduGHy BqbA== X-Gm-Message-State: APjAAAXwfuY3T0aGEpE1MusR+5aF7cg9qQEEFj48J3GctDbLeJlBRhqV Y2LGLrDmYFGaCaAmnCK5DyzzKqzr2KUEd1HUcR/yXw== X-Google-Smtp-Source: APXvYqy8dWCTHo7TUV4AzczEJuMRASGzDDwRJFkdDJcZVTaQeNjMA5exE0p/5mK9P4ixkLMywRdSYZF1Jn9N7oomvHE= X-Received: by 2002:adf:cd02:: with SMTP id w2mr1292790wrm.30.1551844847357; Tue, 05 Mar 2019 20:00:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dustin Dettmer Date: Tue, 5 Mar 2019 20:00:35 -0800 Message-ID: To: Bitcoin Protocol Discussion , Marco Falke Content-Type: multipart/alternative; boundary="000000000000df94e005836508f0" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Wed, 06 Mar 2019 14:35:15 +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 04:00:50 -0000 --000000000000df94e005836508f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The reject message is helpful for figuring out why a tx was rejected. It=E2=80=99s not useful for determining success, yes. Particularly when doi= ng segwit / newer types of tx=E2=80=99s as there=E2=80=99s always one or more = pesky nodes who still don=E2=80=99t support it and send a reject message for perfectly good= tx=E2=80=99s. But after a delay where you haven=E2=80=99t seen your tx propagated on the = network, it=E2=80=99s useful to know *why* it failed. What would be nice is actually expanding this error message. Currently with RBF tx=E2=80=99s =E2=80=9Cfee too small=E2=80=9D is sent for both original = transactions as well as replacement transactions. So a bug accidentally sending spent txos (currently in mempool) says =E2=80=9Cfee too small=E2=80=9D instead of some= thing more appropriate like =E2=80=9Cfee too small to supersede existing unconfirmed transaction.=E2=80=9D On Tue, Mar 5, 2019 at 7:26 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 a= s > of > time of writing). Nodes on the network can not generally be trusted to se= nd > valid ("reject") messages, so this should only ever be used when connecte= d > 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 applicati= on > 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=3D`) to a stream (`-printtoconsole`) or to a file > (`-debuglogfile=3D`). > > * 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 propagatio= n. > > 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 > --000000000000df94e005836508f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The reject message is helpful for figuring out why a= tx was rejected.

= It=E2=80=99s not useful for determining success, yes. Particularly when doi= ng segwit / newer types of tx=E2=80=99s as there=E2=80=99s always one or mo= re pesky nodes who still don=E2=80=99t support it and send a reject message= for perfectly good tx=E2=80=99s.

But after a delay where you haven=E2=80=99t seen your tx propagat= ed on the network, it=E2=80=99s useful to know *why* it failed.

What would be nice is actually expa= nding this error message. Currently with RBF tx=E2=80=99s =E2=80=9Cfee too = small=E2=80=9D is sent for both original transactions as well as replacemen= t transactions. So a bug accidentally sending spent txos (currently in memp= ool) says =E2=80=9Cfee too small=E2=80=9D instead of something more appropr= iate like =E2=80=9Cfee too small to supersede existing unconfirmed transact= ion.=E2=80=9D

On Tue, Mar 5, 2019 at 7:26 PM Marco Falke via bitcoin-de= v <bitcoin-dev@= lists.linuxfoundation.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
--000000000000df94e005836508f0--