summaryrefslogtreecommitdiff
path: root/5d/51146a3516e864149b0875c7ccb39298ffa9e2
blob: b1e58edededc090475cd77e61a925195d491a03c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
Return-Path: <john@johnnewbery.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 89B55E25
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Oct 2019 16:44:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com
	[209.85.210.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AF2B38AB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Oct 2019 16:44:08 +0000 (UTC)
Received: by mail-ot1-f52.google.com with SMTP id 21so20714495otj.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Oct 2019 09:44:08 -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=8SVjWiw5L4qUI21W65wohyiE44OOlP4cekJQ6wteUuQ=;
	b=A/ZbutKb40mlYqkz8rxuxo2DQr/+v16Q3pkt80hadABL95kpwCd+A0X+pfLHe+A5FA
	21424sU/0I9Z2ZhlQ5s8DU8hzMZHGs4jGoIMTvUoL3kj+/amatpVxkHvzlFkD8DV9zRz
	F69TnoqhqgcK2ylxMH21KNqgQodIfuwS3OYU4AB3t729kVgc6JFNNsuTR14Io80dfy25
	YoSmyZ1Gde2jcMznRrAo7WfO96CrHKK2RfItxRwWXK+YDP7wCs/QLIzt9NbNu4TXW6qQ
	UASkoO/sDg8JNQ8/p7CK4kPG6F9oBxULFLwTQDZ8nVEMfpEBz0WrAZdHxS79k57SSJoK
	Xzeg==
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=8SVjWiw5L4qUI21W65wohyiE44OOlP4cekJQ6wteUuQ=;
	b=kY6d8DHZAif8Q0WiAPEBPItKunTeXX6u7k05yi73TNatjKz0gFhKCpzDtLEojfoFaL
	mxJ/rCSQJLrPpQsKm7SFqN6rHMxL2CXGg3iXKkFr+lXa8yHcWgikWG8IdCPuL95lZrt4
	wrawsDQbva/MO4G6UvD+mvw35TXmTpp3usHmZbOQUKTR4NSKVIP8Ku+Ii4SB+Lpg9lqU
	weZBi9GrDfXXiW+91/hubSrzxDcC0Wu1kBkUag+BF1coJU79XhLTWDgcIfQ/9baGh2bU
	5BdjorKSLj/a+ln6bVAqCRuHD2WQ775HO1BkVPZDKhT4pNdeBWFb5G2Q0WRMacrp6qs7
	AdHg==
X-Gm-Message-State: APjAAAUBr/6bW33jvfbLfCpNa5mNECBbeXGOU9yWouaMbeAIYuEj/XEI
	KGPzdA6gkS+pNSHBkJORG5sFVGUBsjE=
X-Google-Smtp-Source: APXvYqyzukCHWnaMqtQYbsXkUdrp5FnNS8a638w4LvNiZ/NLQscOQ27/87aD+gYIJ1qYM9s5l2Wkkg==
X-Received: by 2002:a9d:4902:: with SMTP id e2mr11187925otf.263.1571244247219; 
	Wed, 16 Oct 2019 09:44:07 -0700 (PDT)
Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com.
	[209.85.210.52])
	by smtp.gmail.com with ESMTPSA id b4sm7005860oiy.30.2019.10.16.09.44.06
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
	Wed, 16 Oct 2019 09:44:06 -0700 (PDT)
Received: by mail-ot1-f52.google.com with SMTP id c10so20746027otd.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Oct 2019 09:44:06 -0700 (PDT)
X-Received: by 2002:a9d:61d1:: with SMTP id h17mr31811956otk.254.1571244245810;
	Wed, 16 Oct 2019 09:44:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
In-Reply-To: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
From: John Newbery <john@johnnewbery.com>
Date: Wed, 16 Oct 2019 12:43:53 -0400
X-Gmail-Original-Message-ID: <CAFmfg2u3cLwG4h=tSF1+ho__1n2n4xyBGH+mwQgVYE9c_s+EMw@mail.gmail.com>
Message-ID: <CAFmfg2u3cLwG4h=tSF1+ho__1n2n4xyBGH+mwQgVYE9c_s+EMw@mail.gmail.com>
To: Marco Falke via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000020857a059509cf96"
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: Wed, 16 Oct 2019 17:30:02 +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, 16 Oct 2019 16:44:09 -0000

--00000000000020857a059509cf96
Content-Type: text/plain; charset="UTF-8"

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=<category>`) to a stream (`-printtoconsole`) or to a file
>   (`-debuglogfile=<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 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
>

--00000000000020857a059509cf96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Following discussion on this mailing list, support fo=
r BIP 61 REJECT messages was not removed from Bitcoin Core in V0.19. The be=
haviour in that upcoming release is that REJECT messages are disabled by de=
fault and can be enabled using the `-enablebip61` command line option.<br><=
br>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 i=
nto Bitcoin Core&#39;s master branch this week.<br><br>Adoption of new Bitc=
oin Core versions across reachable nodes generally takes several months. <a=
 href=3D"https://bitnodes.earn.com/dashboard/?days=3D365">https://bitnodes.=
earn.com/dashboard/?days=3D365</a> shows that although v0.18 was released i=
n 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 f=
rom public nodes for troubleshooting issues therefore have plenty of time t=
o transition to one of the methods listed by Marco in the email above.<br><=
/div><div><br></div>John<div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Bitcoin Core may send &quo=
t;reject&quot; messages as response to &quot;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></div>

--00000000000020857a059509cf96--