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
|
Return-Path: <gcbd-bitcoin-development-2@m.gmane.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B2041BA0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Oct 2019 08:44:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from blaine.gmane.org (195-159-176-226.customer.powertech.no
[195.159.176.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90D768B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Oct 2019 08:44:27 +0000 (UTC)
Received: from list by blaine.gmane.org with local (Exim 4.89)
(envelope-from <gcbd-bitcoin-development-2@m.gmane.org>)
id 1iMTIe-0014fk-1f for bitcoin-dev@lists.linuxfoundation.org;
Mon, 21 Oct 2019 10:44:24 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-dev@lists.linuxfoundation.org
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 21 Oct 2019 10:44:16 +0200
Message-ID: <qojr51$7pnq$1@blaine.gmane.org>
References: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
<CAFmfg2u3cLwG4h=tSF1+ho__1n2n4xyBGH+mwQgVYE9c_s+EMw@mail.gmail.com>
<CAFmfg2sU=ur7NdzU6r9bGC=xZqcX7WA7ux-r8QOwNa+FKhS4Pw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Openpgp: preference=signencrypt
Autocrypt: addr=andreas@schildbach.de; keydata=
xsDiBD/S9DARBACgg0IF3cCFaNXbQtCAZBpiZRawQAfsfL87sHhy1xq3UwR4RmQKsWjtZQ9C
7kSDTkzzn7Sqg+YtXgiJdGeYinSMy+6mBKQjtrIKLikbjB1ORTfA29m7m7VTBY9X3Cvmpm0+
0mWvrQ9hSpq8adXitY4Z+/VB/1YSo77RakfNr3sQOwCgzrXH37AlAu307IgOOFnI1y78Y4cD
/29gtaY3/u8ThFI/mXBOHnfXaIVGLYKtlf2Lyj2JnixhhzxEpuDJ0lkcyNQ0N7Ky8ohJS3tG
ShwHjsQNtqK2V1DomsUnDI/W4hJNCSd0zfIoQgHvE1RbOyOpz4F+CNw8uQcxwE5FmwRtk6xa
zJsiMVKLFhKr6LnMoVaNi8mZZFKzA/9HcXAse5epfrZD1tt7dHr58+egIA0OkoQ8oUgqCgN1
4qmUxQoWTdmvet0E+XaHcowr1fXu79uQ2zuvHSk/S4mjP6uT+XOxENVcKRUtyEBtSzFDyyCj
853KrBQSppCgxS8loHj1g1YIKqu97kGVtfmHM9L9TPVA1opuYOcJh7iJ9s0qQW5kcmVhcyBT
Y2hpbGRiYWNoIDxhbmRyZWFzQHNjaGlsZGJhY2guZGU+wl4EExECAB4FAj/S9DACGwMGCwkI
BwMCAxUCAwMWAgECHgECF4AACgkQymYr4YuHemD4NACePnpSANmR2vrZVv+BteOva6gzOJ0A
nioa6JoKCYx3jQOIqoBGcBUkc8q1zsFNBD/S9DgQCACctel4AnL7nuh+Uv+IBz0GMvu6Ewdn
sVCOLf54neIxuaW4BC5RYAdS6Tkp3hxv+ZfA0Uv6X3nz4tOsVHD50+CCq51pRlnbUwcWcn9e
nynJyddTjei+JmJrdOJOAzWa/al8YagjQSZqgD6mmPUy/a201Bh0L2zbLmxQMFg+PPB81j4y
UmSXmhYzg/+SonZ3lr9pJNtoZszg95NDyYBceiF5RSw4Qusi+C5/W3nIKzuaIKZijE9Dvo6D
W6ggbB/gSxDTSjvrnvvXeG1SdlKLeFvsJ9y/0ro3EP01RRVJvA5RaM5W2MRbwGuSRcSw8B74
6ijEOqSh0IYLXoHdV7Vj4Qt/AAMFB/9ZcgxVGvs2ob6MCTVdPLlVKRKDn7RjZiDE6hRa/jp7
ewdstjjc22DU/jCz16IX75B/sr1cDJqbChONFdljjQNWe2cTFXSazUjsyZa35+KvehDi7cAU
+vCYmisMpkPM41hR6HYqjadDp6gOVJTnHPcJ6EPdgUQTsNQH3dCTD68b5WwzBEBNLdwyDGLK
McExzaOClwwSeHBmnj72O7Chdhn/M/2+fpTUPqhp/0sflVyR/ILyc/KEp85pwani2dXuZ02i
gSaSIBwQJOVrjsUTwp2Wxdmywt13/cGGVlsGLe8lY0Kv6G43/eip+42OfIVhxRgARRtJ5KjK
chTLwfl3tbgawkkEGBECAAkFAj/S9DgCGwwACgkQymYr4YuHemAWjACgtRlmiISVlCf7/mum
klJfLM6wKIMAnA2uS1BS4d7GJkQp09ViaWmUUsMc
In-Reply-To: <CAFmfg2sU=ur7NdzU6r9bGC=xZqcX7WA7ux-r8QOwNa+FKhS4Pw@mail.gmail.com>
Content-Language: en-US
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL,
KHOP_HELO_FCRDNS,RDNS_DYNAMIC autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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: Mon, 21 Oct 2019 08:44:28 -0000
I guess then the best way to discover nodes that have reject messages
enabled is connecting/disconnecting to random nodes and send them
invalid transactions and keep the ones which reply with a reject message.
On 18/10/2019 22.53, John Newbery via bitcoin-dev wrote:
>> 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 <john@johnnewbery.com
> <mailto:john@johnnewbery.com>> 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
> <mailto: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
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
