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
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D94B4A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 07:07:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com
[74.125.82.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01EDB198
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 07:07:33 +0000 (UTC)
Received: by mail-ot0-f172.google.com with SMTP id r67so83544052ota.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 00:07:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:cc:in-reply-to:to;
bh=VNkrYDgieOUmc4EzQ65mWeTjSB7XEQXZAJO6fjvn9qQ=;
b=ne/fkI5I0tWkapAVV7SGvkgFdgbUTKREEn15jawt5Q6SgIz5aDkGNvst6kgBCk8E0F
lZds8wYFGkOxZbc1xqpTa7+gLeSVqUQtP1VHZxs+9ZtlyrX/oVNM2JegoItdBH1ardo6
qzs5SwJD+Meqw8/z4ghoOlw8fb2+IoWzhKGyClgXfJFJMydw81tep5hxZScvVNhLWrPx
OqgaVeWehthHDsRkkwOTBFRhSgDfN/RBAWF/A/+heBhkY6Us+hDmwH587nPRx8x51zxN
hV78YPjtFqs6DudqP4LLR3XqRcN5hxHNFGrIlSz/Uwc0XJOAmyJdnE0UcZmGbLoQdTNG
uB/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:cc:in-reply-to:to;
bh=VNkrYDgieOUmc4EzQ65mWeTjSB7XEQXZAJO6fjvn9qQ=;
b=cGqFOe55VsASN7cTPdcTUnju8yTZDSDkBdHf8FbR5KdVyF8tiZhzHekXLOWmDU3svF
L5Ec+ua52iUDSeVV16ScrZjID6JqNi7CMfoFsu/zvSGRJ495ChIm4Frm9yzGkedIoNG/
4EpaxTpu+XHUJvwxnXk5XPg4KOsXK6DVfHd3Jmpe0Uh9FC9O1kBtDy7fZ2dPoofMFvbG
G7EZEPP9lXuUnKSI3919WEDu3j5LmDgEprZmU07hUNx1HyH7smVdTnbDpMRJeO8DVmdB
7dj3Hu+Z9FIsLm824G97lPA1l31SQ3h1cOtnma1HLKlKBI9jCEnA7i22xL6hyX8KUZto
iumg==
X-Gm-Message-State: AKS2vOyils8HT4sCRJuThu9mNED80iL+bRGITId1GX7GgSkN5OGoynmO
WaOYx8VtN3b5PDbo4mJDdQ==
X-Received: by 10.157.24.68 with SMTP id t4mr13714136ott.230.1497942453208;
Tue, 20 Jun 2017 00:07:33 -0700 (PDT)
Received: from [10.201.157.86] (mobile-107-107-184-57.mycingular.net.
[107.107.184.57])
by smtp.gmail.com with ESMTPSA id o8sm4507705oig.7.2017.06.20.00.07.24
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 20 Jun 2017 00:07:32 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Tue, 20 Jun 2017 09:03:43 +0200
Message-Id: <5E00D8BD-234F-449C-AF52-F7EB4B814306@voskuil.org>
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
<oi8e8k$g56$1@blaine.gmane.org>
<537fb7106e0387c77537f0b1279cbeca@cock.lu>
<55482016.LADLl5KXAH@strawberry>
<4052F361-966C-4817-9779-146D4B43D1FE@jonasschnelli.ch>
<oi8sdn$ksl$1@blaine.gmane.org>
<B27FF856-9281-479C-BFE2-D594F46C5C44@jonasschnelli.ch>
In-Reply-To: <B27FF856-9281-479C-BFE2-D594F46C5C44@jonasschnelli.ch>
To: Jonas Schnelli <dev@jonasschnelli.ch>
X-Mailer: iPhone Mail (14F89)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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: Tue, 20 Jun 2017 09:39:52 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
Light Clients
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: Tue, 20 Jun 2017 07:07:35 -0000
The reason that BIP37 presents a long list of problems is that it is a clien=
t-server scenario wedged into a peer-to-peer network. The only possible excu=
se for this design was implementation shortcut.
As this thread and others demonstrate, reproducing this design flaw will not=
eliminate the problems. The fact that there are many wallets dependent upon=
it is an unfortunate consequence of the original sin, but is not likely to l=
ast. There is no rationale for node operators to support wallets apart from t=
heir own. As a node implementer interested in privacy, security and scalabil=
ity, I would never waste the time to code BIP37, or and client-server featur=
e into the P2P protocol, especially one that delegates some aspect of valida=
tion.
Other nodes (servers) provide independent, securable, client-server interfac=
es. Many of these are made available as community servers for use at no char=
ge. They could also provide mechanisms for operator payment without pollutin=
g the P2P network.
However as a community we should be working toward full node wallets. A secu=
red personal node/server can support remote mobile wallets with security, pr=
ivacy and no wasted bandwidth. And if we avoid counterproductive increases i=
n blockchain growth rate, full nodes will eventually be able to run on mobil=
e platforms with no difficulty whatsoever. A wallet that delegates full vali=
dation to node operators is just another centralization pressure that we do n=
ot need.
e
On Jun 19, 2017, at 6:22 PM, Jonas Schnelli via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>>=20
>> On the other hand, I remember only 1 (one) inquiry about the privacy
>> problems of BIP37 (or privacy at all).
>=20
> IMO privacy its something developers should make sure users have it.
> Also, I think, todays SPV wallets should make users more aware of the poss=
ible privacy implications.
>=20
> Do users know, if they pay for a good in a shop while consuming the shops W=
IFI, that the shop-owner as well as the ISP can use that data to combine it w=
ith the user profile (and ~ALL FUTURE purchases you do with the same wallet I=
N ANY LOCATION online or in-person)?
>=20
> Do users know, that ISPs (cellular; including Google) can completely link t=
he used Bitcoin wallet (again: all purchase including future ones) with the t=
o the ISP well known user profile including credit-card data and may sell th=
e Bitcoin data to any other data mining company?
>=20
> If you use BIP37, you basically give your transaction history (_ALL TRANSA=
CTIONS_ including transactions in future) to everyone.
>=20
>=20
>>=20
>> =46rom a regular user's point of view, privacy is non-issue. Sure,
>> everyone would take it for free, but certainly not if it a) delays
>> incoming payments or b) quickly eats up your traffic quota.
>=20
> This may be true because they are not aware of the ramification and I don=E2=
=80=99t think client side filtering is a drop-in replacement for todays, sma=
rtphone SPV-model.
>=20
>=20
> /jonas
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
