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>
Cc: bitcoin-dev@lists.linuxfoundation.org,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
	Light Clients
Precedence: list

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