summaryrefslogtreecommitdiff
path: root/20/deff774b1af7a3f8225c7509642391b32f667e
blob: 689c40fa9749360e710f0d94411710c6c0baa87a (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
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 47192E91
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 14 Aug 2019 15:07:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7357587E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 14 Aug 2019 15:07:21 +0000 (UTC)
Received: from [IPv6:2620:6e:a000:1000:6066:6448:93c9:2ea2] (unknown
	[IPv6:2620:6e:a000:1000:6066:6448:93c9:2ea2])
	by mail.bluematt.me (Postfix) with ESMTPSA id A4B7C9988A;
	Wed, 14 Aug 2019 15:07:19 +0000 (UTC)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-AD753205-B2A6-4770-B13F-01C5E674E100
Mime-Version: 1.0 (1.0)
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <FF0175BF-1D1F-4AD4-9B13-99D522DBCD83@bridge21.com>
Date: Wed, 14 Aug 2019 11:07:19 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <C345325B-D0DE-42FD-849E-5DEF4BBC3C59@mattcorallo.com>
References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com>
	<FF0175BF-1D1F-4AD4-9B13-99D522DBCD83@bridge21.com>
To: Will Madden <will.madden@bridge21.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MIME_QP_LONG_LINE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by
	default
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, 14 Aug 2019 15:07:22 -0000


--Apple-Mail-AD753205-B2A6-4770-B13F-01C5E674E100
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

You very clearly didn't bother to read other mails in this thread. To make i=
t easy for you, here's a few links:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017147.htm=
l
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017175.htm=
l

Matt

> On Aug 13, 2019, at 23:05, Will Madden <will.madden@bridge21.com> wrote:
>=20
> For the record, strong NACK. My understanding is that this breaks several e=
stablished SPV implementations (such as early breadwallet for sure and possi=
bly current BRD wallets) and I have yet to see quantitative prioritization o=
r even a rational justification for this change.
>=20
> Requiring SPV wallets to communicate with trusted nodes is centralization,=
 and breaking functionality and implementations that enable this without a t=
horoughly researched rationale is highly suspect.
>=20
>> On Jul 20, 2019, at 1:46 PM, Matt Corallo via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>>=20
>> Just a quick heads-up for those watching the list who may be using it -
>> in the next Bitcoin Core release bloom filter serving will be turned off
>> by default. This has been a long time coming, it's been an option for
>> many releases and has been a well-known DoS vector for some time.
>> As other DoS vectors have slowly been closed, this has become
>> increasingly an obvious low-hanging fruit. Those who are using it should
>> already have long been filtering for NODE_BLOOM-signaling nodes, and I
>> don't anticipate those being gone any time particularly soon.
>>=20
>> See-also PR at https://github.com/bitcoin/bitcoin/pull/16152
>>=20
>> The release notes will liekly read:
>>=20
>> P2P Changes
>> -----------
>> - The default value for the -peerbloomfilters configuration option (and,
>> thus, NODE_BLOOM support) has been changed to false.
>> This resolves well-known DoS vectors in Bitcoin Core, especially for
>> nodes with spinning disks. It is not anticipated that
>> this will result in a significant lack of availability of
>> NODE_BLOOM-enabled nodes in the coming years, however, clients
>> which rely on the availability of NODE_BLOOM-supporting nodes on the
>> P2P network should consider the process of migrating
>> to a more modern (and less trustful and privacy-violating) alternative
>> over the coming years.
>>=20
>> Matt
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-AD753205-B2A6-4770-B13F-01C5E674E100
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">You=
 very clearly didn't bother to read other mails in this thread. To make it e=
asy for you, here's a few links:</div><div dir=3D"ltr"><a href=3D"https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017147.html">https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017147.html</a></=
div><div dir=3D"ltr"><a href=3D"https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2019-July/017175.html">https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2019-July/017175.html</a></div><div dir=3D"ltr"><br></div><di=
v dir=3D"ltr">Matt</div><div dir=3D"ltr"><br>On Aug 13, 2019, at 23:05, Will=
 Madden &lt;<a href=3D"mailto:will.madden@bridge21.com">will.madden@bridge21=
.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div dir=3D"ltr">=
<span>For the record, strong NACK. My understanding is that this breaks seve=
ral established SPV implementations (such as early breadwallet for sure and p=
ossibly current BRD wallets) and I have yet to see quantitative prioritizati=
on or even a rational justification for this change.</span><br><span></span>=
<br><span>Requiring SPV wallets to communicate with trusted nodes is central=
ization, and breaking functionality and implementations that enable this wit=
hout a thoroughly researched rationale is highly suspect.</span><br><span></=
span><br><blockquote type=3D"cite"><span>On Jul 20, 2019, at 1:46 PM, Matt C=
orallo via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</span><br></blo=
ckquote><blockquote type=3D"cite"><span></span><br></blockquote><blockquote t=
ype=3D"cite"><span>Just a quick heads-up for those watching the list who may=
 be using it -</span><br></blockquote><blockquote type=3D"cite"><span>in the=
 next Bitcoin Core release bloom filter serving will be turned off</span><br=
></blockquote><blockquote type=3D"cite"><span>by default. This has been a lo=
ng time coming, it's been an option for</span><br></blockquote><blockquote t=
ype=3D"cite"><span>many releases and has been a well-known DoS vector for so=
me time.</span><br></blockquote><blockquote type=3D"cite"><span>As other DoS=
 vectors have slowly been closed, this has become</span><br></blockquote><bl=
ockquote type=3D"cite"><span>increasingly an obvious low-hanging fruit. Thos=
e who are using it should</span><br></blockquote><blockquote type=3D"cite"><=
span>already have long been filtering for NODE_BLOOM-signaling nodes, and I<=
/span><br></blockquote><blockquote type=3D"cite"><span>don't anticipate thos=
e being gone any time particularly soon.</span><br></blockquote><blockquote t=
ype=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>S=
ee-also PR at <a href=3D"https://github.com/bitcoin/bitcoin/pull/16152">http=
s://github.com/bitcoin/bitcoin/pull/16152</a></span><br></blockquote><blockq=
uote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><=
span>The release notes will liekly read:</span><br></blockquote><blockquote t=
ype=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>P=
2P Changes</span><br></blockquote><blockquote type=3D"cite"><span>----------=
-</span><br></blockquote><blockquote type=3D"cite"><span>- The default value=
 for the -peerbloomfilters configuration option (and,</span><br></blockquote=
><blockquote type=3D"cite"><span>thus, NODE_BLOOM support) has been changed t=
o false.</span><br></blockquote><blockquote type=3D"cite"><span> This resolv=
es well-known DoS vectors in Bitcoin Core, especially for</span><br></blockq=
uote><blockquote type=3D"cite"><span>nodes with spinning disks. It is not an=
ticipated that</span><br></blockquote><blockquote type=3D"cite"><span> this w=
ill result in a significant lack of availability of</span><br></blockquote><=
blockquote type=3D"cite"><span>NODE_BLOOM-enabled nodes in the coming years,=
 however, clients</span><br></blockquote><blockquote type=3D"cite"><span> wh=
ich rely on the availability of NODE_BLOOM-supporting nodes on the</span><br=
></blockquote><blockquote type=3D"cite"><span>P2P network should consider th=
e process of migrating</span><br></blockquote><blockquote type=3D"cite"><spa=
n> to a more modern (and less trustful and privacy-violating) alternative</s=
pan><br></blockquote><blockquote type=3D"cite"><span>over the coming years.<=
/span><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquo=
te><blockquote type=3D"cite"><span>Matt</span><br></blockquote><blockquote t=
ype=3D"cite"><span>_______________________________________________</span><br=
></blockquote><blockquote type=3D"cite"><span>bitcoin-dev mailing list</span=
><br></blockquote><blockquote type=3D"cite"><span><a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></sp=
an><br></blockquote><blockquote type=3D"cite"><span><a href=3D"https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev</a></span><br></blockquote></div></blo=
ckquote></body></html>=

--Apple-Mail-AD753205-B2A6-4770-B13F-01C5E674E100--