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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
|
Return-Path: <bfd@cock.lu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E5FF1BF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Jan 2017 02:15:30 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from cock.li (cock.li [185.100.85.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C95ECCD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Jan 2017 02:15:29 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.lu; s=mail;
t=1483668926; bh=2vu9yfIJCBqO8SOH1/wDULxfobEE31Pe18+h16lFvMM=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=1L5MvURuM81uIs5434vJ3Vae54Xlw8Lq2ZhRIt6E/hhIppNMlBN9RtQy0DXsKDQo+
v+gr9uJBUVzSHjJW7AlcZV2KSRuPpAy56l6+I2hWtVQSNy+7ZMu7IbOPD/+8xHVfcp
1KIy4Xx99Ns+8UEPF5hchSK+4R0qDeVvyDsUkFJLUDsKW3+BpnhZdnZSKME92liZqv
asPWUyvFgMVzBQWRhQBSLbD5ouAfb74P5jtV2MUHIokHha9keNZK0OFn37YnF9VE5x
hcafny3MN41lSad1Ceo81BZZMNB9fCpPAvky2OE/t7c+6vph+QjfCFEGuCCabLdxdt
Ju/ekeqcmWzcQ==
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 05 Jan 2017 18:15:26 -0800
From: bfd@cock.lu
To: Aaron Voisine <voisine@gmail.com>
In-Reply-To: <CACq0ZD7xdYVaBGs-xCjN2RFKcF5q_RNA1nRmjgU-k2x9VotY_Q@mail.gmail.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
<f335731c-3928-6694-5ed8-aa1999b401f1@jonasschnelli.ch>
<CACq0ZD7xdYVaBGs-xCjN2RFKcF5q_RNA1nRmjgU-k2x9VotY_Q@mail.gmail.com>
Message-ID: <452d837c74b4746e781d8701c68b2205@cock.lu>
X-Sender: bfd@cock.lu
User-Agent: Roundcube Webmail/1.2.3
X-Mailman-Approved-At: Fri, 06 Jan 2017 08:56:12 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 06 Jan 2017 02:15:31 -0000
With a credit card you have an institution worth billions of dollars
asserting that a payment has been made, with the option that it may be
retracted under special circumstances by the card issuer.
Unconfirmed Bitcoin transactions with a SPV client has you trusting
that the un-authenticated DNS seed lookup has not been tampered with,
the connection to the random node that you connect to has not been
tampered with, and that the seed nor the node are attempting to
manipulate you.
The two scenarios aren’t even remotely comparable.
On 2017-01-04 00:56, Aaron Voisine wrote:
> It's easy enough to mark a transaction as "pending". People with bank
> accounts are familiar with the concept.
>
> Although the risk of accepting gossip information from multiple random
> peers, in the case where the sender does not control the receivers
> network is still minimal. Random node operators have no incentive to
> send fake transactions, and would need to control all the nodes a
> client connects to, and find a non-false-positive address belonging to
> the victims wallet.
>
> It's not impossible, but it's non trivial, would only temporarily show
> a pending transaction, and provide no benefit to the node operator.
> There are much juicier targets for an attacker with the ability to
> sybil attack the entire bitcoin p2p network.
>
> Aaron
>
> On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev@jonasschnelli.ch>
> wrote:
>
>> 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.
>>
>>>
>>
>>> 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 – sooner or later
>> – 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...
>>
>> ... disable unconfirmed transactions during SPV against random peers
>>
>> ... enable unconfirmed transactions when using SPV against a trusted
>>
>> peer with preshared keys after BIP150
>>
>> ... if unconfirmed transactions are disabled, show how it can be
>> enabled
>>
>> (how to run a full-node [in a box, etc.])
>>
>> ... educate, inform users that a transaction with no confirmation
>> can be
>>
>> "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 – for the sake of stability
>> and
>>
>> (risk-)scaling – we may want to recommend to scarify this feature
>> and –
>>
>> in the same turn – to use privacy-preserving BFD's.
>>
>> </jonas>
|
