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: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CA8995D
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
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, 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 <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--
|
