path: root/bd/b365355183495ba28b1a3335946faee8f06a29

Return-Path: <dustinpaystaxes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 214B938A0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Mar 2019 04:00:49 +0000 (UTC)
Received: by mail-wr1-f53.google.com with SMTP id i12so11742443wrw.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
In-Reply-To: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Tue, 5 Mar 2019 20:00:35 -0800
Message-ID: <CABLeJxTuWa-Kaht3PgvwGN5Eb3GW=HpS7uNMESMcLpqn4BgN3Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
	Marco Falke <falke.marco@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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<category>`) to a stream (`-printtoconsole`) or to a file
>   (`-debuglogfile=3D<debug.log>`).
>
> * 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

<div><div dir=3D"auto">The reject message is helpful for figuring out why a=
 tx was rejected.</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
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.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">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.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">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</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, Mar 5, 2019 at 7:26 PM Marco Falke via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Bitcoin Core may send &quot;reject&quot; messages as response to &quo=
t;tx&quot;, &quot;block&quot; or<br>
&quot;version&quot; messages from a network peer when the message could not=
 be accepted.<br>
<br>
This feature is toggled by the `-enablebip61` command line option and has b=
een<br>
disabled by default since Bitcoin Core version 0.18.0 (not yet released as =
of<br>
time of writing). Nodes on the network can not generally be trusted to send=
<br>
valid (&quot;reject&quot;) messages, so this should only ever be used when =
connected to a<br>
trusted node. At this time, I am not aware of any software that requires th=
is<br>
feature, and I would like to remove if from Bitcoin Core to make the codeba=
se<br>
slimmer, easier to understand and maintain. Let us know if your application=
<br>
relies on this feature and you can not use any of the recommended alternati=
ves:<br>
<br>
* Testing or debugging of implementations of the Bitcoin P2P network protoc=
ol<br>
=C2=A0 should be done by inspecting the log messages that are produced by a=
 recent<br>
=C2=A0 version of Bitcoin Core. Bitcoin Core logs debug messages<br>
=C2=A0 (`-debug=3D&lt;category&gt;`) to a stream (`-printtoconsole`) or to =
a file<br>
=C2=A0 (`-debuglogfile=3D&lt;debug.log&gt;`).<br>
<br>
* Testing the validity of a block can be achieved by specific RPCs:<br>
=C2=A0 - `submitblock`<br>
=C2=A0 - `getblocktemplate` with `&#39;mode&#39;` set to `&#39;proposal&#39=
;` for blocks with<br>
=C2=A0 =C2=A0 potentially invalid POW<br>
<br>
* Testing the validity of a transaction can be achieved by specific RPCs:<b=
r>
=C2=A0 - `sendrawtransaction`<br>
=C2=A0 - `testmempoolaccept`<br>
<br>
* Wallets should not use the absence of &quot;reject&quot; messages to indi=
cate a<br>
=C2=A0 transaction has propagated the network, nor should wallets use &quot=
;reject&quot;<br>
=C2=A0 messages to set transaction fees. Wallets should rather use fee esti=
mation<br>
=C2=A0 to determine transaction fees and set replace-by-fee if desired. Thu=
s, they<br>
=C2=A0 could wait until the transaction has confirmed (taking into account =
the fee<br>
=C2=A0 target they set (compare the RPC `estimatesmartfee`)) or listen for =
the<br>
=C2=A0 transaction announcement by other network peers to check for propaga=
tion.<br>
<br>
I propose to remove &quot;reject&quot; messages from Bitcoin Core 0.19.0 un=
less there are<br>
valid concerns about its removal.<br>
<br>
Marco<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000df94e005836508f0--