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
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A0B0ED35F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 14:05:29 +0000 (UTC)
X-Greylist: delayed 00:05:38 by SQLgrey-1.7.6
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
[66.111.4.26])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CF6AD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Mar 2019 14:05:28 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id 70E2122291;
Thu, 7 Mar 2019 08:59:50 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute1.internal (MEProxy); Thu, 07 Mar 2019 08:59:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
from:content-type:content-transfer-encoding:mime-version:subject
:date:references:to:in-reply-to:message-id; s=fm2; bh=zel/LzqTX5
o88p/31C8rY0s7s3JYpqRpOJUH+CAYMrI=; b=Y2A3/B7QQ6naBocHdWI+TMvDJA
XmkbXkI7BLPKtlY3XN5rYFn9k/r5KPodTrxqrnN1+iCqrI4J1BMi7Fbk1ZXTem76
NsyUcfCXLD0pTC9FXVskjgEFurmrrtp9PbIfpLvnVVXBnjZIEYZ4hU4OTgeaiGKw
sAjKrI7YnYdIZm+FZkIUfQiUz8GWt6HC+M2PYck3LrgwXtNG5Lub7J4rd0YI6MU4
wAWG33g9pZMr9eY4NgHW3bkAP6ymttwqK0hlVGZjjvXAMybqF40hYEqDvSE9/N3v
LRBjGUbJNZKPyEWFuA9odQQrbgNzk6dmHjrBpii0VzmszPHVM/YsaV7WLbBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; bh=zel/LzqTX5o88p/31C8rY0s7s3JYpqRpOJUH+CAYM
rI=; b=LDruTQZq/Z4JV4L5vODFM8ykJz1B4vkd9y++AVPdOwawPWu+xnNaQ/rAv
pf8F6InMHWHzj7Eq6N4dBlhGhtOpZI0Lx7GO0RMG2/LbMkzepy4dU+eD+ZT+pb8N
L+md8C6xVye144PLInPE1nO6i7HAJxLXShLyEn7862Ld3MoPPZZFekJxZW+nFrlk
2OgImdIIOfcLY1Ou68Rja/kpuWJOLhc0zOcgyu+7wBTCpDjJEKlEIVdut21stnrc
PKqlJ+8+fCqC7eSt9G+f9irMStLXlY/yFtCf3nLlspmZFg+UcC1/gIHLfwXchwGA
uhxadP83VPLZeLo/TRMEuF9Ra1PIA==
X-ME-Sender: <xms:1SOBXFBDTiZEPR-F-ff9GmibqgWhLScxUUkELENKs2muecQ7IqhEkg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeekgdeitdcutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhtgfgggfuffhfvfgjkffosehtqhhmtdhhtddvnecuhfhrohhmpefujhhorhhs
ucfrrhhovhhoohhsthcuoehsjhhorhhssehsphhrohhvohhoshhtrdhnlheqnecuffhomh
grihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgnecukfhppeekgedruddthedr
iedurdduheenucfrrghrrghmpehmrghilhhfrhhomhepshhjohhrshesshhprhhovhhooh
hsthdrnhhlnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:1SOBXHx-sa4DBwyVg6XojNFh5pPrI8qrjUBMxhXD26cTVYng3W_ljg>
<xmx:1SOBXLkvMb39gfT2h495vMuP1W5jdGZtg_5vui6QBFkYcAUGO3m2hw>
<xmx:1SOBXEGRXDpFLZTrVGxRFCZoQmcI5RvYmL5tquB1zMj8aTEHRPQSRA>
<xmx:1iOBXCN7Gtjak2U_7Hae_egA41YSe-BeojwHPeFKY0cnThVxVX-8-A>
Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl
[84.105.61.15])
by mail.messagingengine.com (Postfix) with ESMTPA id 2A65CE408B;
Thu, 7 Mar 2019 08:59:49 -0500 (EST)
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 7 Mar 2019 14:59:47 +0100
References: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
<q5otmg$4vh7$1@blaine.gmane.org>
To: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <q5otmg$4vh7$1@blaine.gmane.org>
Message-Id: <78CAF294-56E2-477C-B46F-C65A56357820@sprovoost.nl>
X-Mailer: Apple Mail (2.3445.102.3)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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: Thu, 07 Mar 2019 14:29:49 +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: Thu, 07 Mar 2019 14:05:29 -0000
Can you elaborate a bit on what kind of reject messages your users are =
getting? I assume the users wallet connects directly to the Bitcoin p2p =
network?
What does the wallet do when a transaction is rejected? Does it forget =
about it (that seems unsafe) or compose another one (with overlapping =
inputs)?
Sjors
> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> Reject messages cannot be replaced for debugging user problems. At =
least
> unless you plan to make RPC or bitcoind logfiles available via the P2P
> protocol (both probably not a good idea).
>=20
> The typical case is, I get mailed a wallet logfile with reject =
messages
> and that's all I have. I cannot access the bitcoind logfile(s) of the
> node(s) that generated the reject message in the first place. Nor can =
I
> access their RPC interface.
>=20
> I strongly suggest re-enabling reject messages by default before 0.18.
>=20
>=20
> On 06/03/2019 01.53, Marco Falke via bitcoin-dev 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.
>>=20
>> 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:
>>=20
>> * 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>`).
>>=20
>> * 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
>>=20
>> * Testing the validity of a transaction can be achieved by specific =
RPCs:
>> - `sendrawtransaction`
>> - `testmempoolaccept`
>>=20
>> * 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.
>>=20
>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless =
there are
>> valid concerns about its removal.
>>=20
>> Marco
>>=20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
