To: Aaron Voisine <voisine@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	bfd@cock.lu
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
	<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
	<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
	<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <f335731c-3928-6694-5ed8-aa1999b401f1@jonasschnelli.ch>
Date: Wed, 4 Jan 2017 08:47:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
	Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="nGcwufmwGqeIC3Dr9AFjNuI8uneeXRpXF"
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
 performance and SPV security
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--nGcwufmwGqeIC3Dr9AFjNuI8uneeXRpXF
Content-Type: multipart/mixed; boundary="x9aFJsNlNhaFFHF5EusBRDoraOgkFPNP4";
 protected-headers="v1"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: Aaron Voisine <voisine@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 bfd@cock.lu
Message-ID: <f335731c-3928-6694-5ed8-aa1999b401f1@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
 performance and SPV security
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
 <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
 <74aeb4760316b59a3db56c0d16d11f28@cock.lu>
 <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
In-Reply-To: <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>

--x9aFJsNlNhaFFHF5EusBRDoraOgkFPNP4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi

> Unconfirmed transactions are incredibly important for real world use.
> Merchants for instance are willing to accept credit card payments of
> thousands of dollars and ship the goods despite the fact that the
> transaction can be reversed up to 60 days later. There is a very large
> cost to losing the ability to have instant transactions in many or
> even most situations. This cost is typically well above the fraud risk.=
=20
>
> It's important to recognize that bitcoin serves a wide variety of use
> cases with different profiles for time sensitivity and fraud risk.
>
I agree that unconfirmed transactions are incredibly important, but not
over SPV against random peers.

If you offer users/merchants a feature (SPV 0-conf against random
peers), that is fundamentally insecure, it will =E2=80=93 sooner or later=
 =E2=80=93 lead
to some large scale fiasco, hurting Bitcoins reputation and trust from
merchants.

Merchants using and trusting 0-conf SPV transactions (retrieved from
random peers) is something we should **really eliminate** through
education and by offering different solution.

There are plenty, more sane options. If you can't run your own full-node
as a merchant (trivial), maybe co-use a wallet-service with centralized
verification (maybe use two of them), I guess Copay would be one of
those wallets (as an example). Use them in watch-only mode.

For end-users SPV software, I think it would be recommended to...
=2E.. disable unconfirmed transactions during SPV against random peers
=2E.. enable unconfirmed transactions when using SPV against a trusted
peer with preshared keys after BIP150
=2E.. if unconfirmed transactions are disabled, show how it can be enable=
d
(how to run a full-node [in a box, etc.])
=2E.. educate, inform users that a transaction with no confirmation can b=
e
"stopped" or "redirected" any time, also inform about the risks during
low-conf phase (1-5).

I though see the point that it's nice to make use of the "incoming
funds..." feature in SPV wallets. But =E2=80=93 for the sake of stability=
 and
(risk-)scaling =E2=80=93 we may want to recommend to scarify this feature=
 and =E2=80=93
in the same turn =E2=80=93 to use privacy-preserving BFD's.

</jonas>



--x9aFJsNlNhaFFHF5EusBRDoraOgkFPNP4--

--nGcwufmwGqeIC3Dr9AFjNuI8uneeXRpXF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlhsqH4ACgkQKdS8tkFv
U+yN0A//WjsM9PMrzrQfqAb3+TFIG0aSBmDG19ssgfet9jc7+zDzxIYyjLdy9+dg
q8qiAg8PJTsd1/mDYTaCWW1p4XKMoo9mxyeWh+GM527KTrOe/rJdEagOeDRIWa8A
QLfpfa87wy2zFO/ghcFmTe0hBr4pC+jQjXOJ2ecGaW3JeSJyw0+Qc4BToxDJLevm
otW2ie8jfMmdDiwF6MKlqsaBY0jEL1MpFGU9IeMqfJHx5a/2ODSnQj8mFaUQVBPD
JVu4VuBDRGOkniSHt6+Zegoom1CbOpaX24z6cRYwzLJxO+rFd0OtHAVk4wZ2oF8L
stJrxn+FnLe8Z2L9+aVZa51tJn2X+HB3kln4jzJBCpozyr0s4jycniJNAwHTjtKu
zaLyqEFcUjsJfYCFfXIAQTW1EOJQV5BKCzKy+OhFpeoNWuXGOWwKF+tuP89GO0Ic
hCu13Yo27ERypi2wD2FMkvqv122QyVaLhxl0VWR8rsY0ibZLiqowZ7PiLAuppcmC
Aieuag3S679CM1TTwD0csrjnUXrybL9i2yDkNueQFySbGEczG+s7JPqNcGlbS40t
fjlAfW9wsO6oQIXXpqHMXJnH4nPRpauXc1+bpvFm6nKJLUNJ1NV5rf/fkpc4bsMz
jQ1ejZkLPe4WIdwbj8wjhfT7ce/dJlWp2uaLr/aZSzWYACqxgD0=
=qFEU
-----END PGP SIGNATURE-----

--nGcwufmwGqeIC3Dr9AFjNuI8uneeXRpXF--