From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CA8995D for ; Wed, 4 Jan 2017 07:47:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3DCDF8C for ; Wed, 4 Jan 2017 07:47:15 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 19FC02E200B4; Wed, 4 Jan 2017 08:47:14 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id 52A9E2D006D0; Wed, 4 Jan 2017 08:47:13 +0100 (CET) To: Aaron Voisine , Bitcoin Protocol Discussion , bfd@cock.lu References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> From: Jonas Schnelli Message-ID: 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: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 07:47:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nGcwufmwGqeIC3Dr9AFjNuI8uneeXRpXF Content-Type: multipart/mixed; boundary="x9aFJsNlNhaFFHF5EusBRDoraOgkFPNP4"; protected-headers="v1" From: Jonas Schnelli To: Aaron Voisine , Bitcoin Protocol Discussion , bfd@cock.lu Message-ID: 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> In-Reply-To: --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. --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--