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"
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin
 Core (BIP61)
Precedence: list

--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--