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
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
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 D6FC7B75
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Jan 2017 00:10:19 +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 8E64A136
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Jan 2017 00:10:18 +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=1483488615; bh=kmz+f13tQtXw7G9r1a75Xh2cf61EwH4HQvX2rP2d6Pc=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=DSUw9Nf6RBWY3LGnjwXuxTH9MlqpSnY0JH+QPZcLa0ERe1P7imNkHCNcZ2KVXyBUc
KmzM5jbOs3W5jv8NdOlex5TU0LszPdUPvziteMyl9xO2hzzEFAvaYCvMuWuRGEYpPI
aJ0FJmiK9RYVh74/ykgPX3Dh720pXGK0c2MinEccW91wTWVb7cVNF//efrPbOByQ5P
PytAo6UH8iv7E+l+hes4s1/2W3ie6mqSgkuGWMjjxnyCLDcrmH1dqttWwrlP2dkoUx
DuWAULOZ9FUoLKP7Qi0MFoqIoF3Vdr/KQNvqedm3mQhYc4s8tPq9ApmSRtU2tPwrRV
1j+OBGSgF3NmQ==
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 03 Jan 2017 16:10:14 -0800
From: bfd@cock.lu
To: Aaron Voisine <voisine@gmail.com>
In-Reply-To: <CACq0ZD5WV7ORmEJgGSquyRzndH_XP9FrLbwSNKQC5Zuh08NVDw@mail.gmail.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
<CAKEeUhiQiUA_E6JF22foV11-WnGZH+kEzfUhROm=gvVN1qMr4A@mail.gmail.com>
<CACq0ZD5WV7ORmEJgGSquyRzndH_XP9FrLbwSNKQC5Zuh08NVDw@mail.gmail.com>
Message-ID: <22b7d05fb2b8a7a0f1c2fa0b6b375f7e@cock.lu>
X-Sender: bfd@cock.lu
User-Agent: Roundcube Webmail/1.2.3
X-Mailman-Approved-At: Wed, 04 Jan 2017 00:18:03 +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: Wed, 04 Jan 2017 00:10:20 -0000
Unfortunately a non validating SPV wallet has absolutely no idea if
the information about an unconfirmed transaction they are seeing is
anything but properly formatted. They are connecting to an easily
manipulated, sybil attacked, and untrusted network and then asking
them for financial information. Seeing an unconfirmed transaction in a
wallet that's not also fully validating is at best meaningless.
On 2017-01-03 15:46, Aaron Voisine wrote:
> If the sender doesn't control the receiver's network connection, then
> the information the receiver gains by watching the mempool is if the
> transaction has propagated across the bitcoin network. This is useful
> to know in all kinds of situations.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet [2]
> On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx@awsomnet.org> wrote:
>
>> Mempool transactions have their place, but "unconfirmed" and "SPV"
>> don't belong together. Only a full node can tell if a transaction
>> may get confirmed, or is nonsense. Unfortunately all the light /
>> SPV wallets I know of show mempool transactions, which makes it hard
>> to go back... (e.g. "why doesn't your software show 0-conf! your
>> wallet is broken!", somewhat akin to people complaining about RBF)
>>
>> So, this is easy, just don't worry about mempool filtering. Why are
>> light clients looking at the mempool anyway? Maybe if there were
>> some way to provide SPV proofs of all inputs, but that's a bit of a
>> mess for full nodes to do.
>>
>> Without mempool filtering, I think the committed bloom filters would
>> be a great improvement over the current bloom filter setup,
>> especially for lightning network use cases (with lightning, not
>> finding out about a transaction can make you lose money). I want to
>> work on it and may be able to at some point as it's somewhat related
>> to lightning.
>>
>> Also, if you're running a light client, and storing the filters the
>> way you store block headers, there's really no reason to go all the
>> way back to height 0. You can start grabbing headers at some point
>> a while ago, before your set of keys was generated. I think it'd be
>> very worth it even with GB-scale disk usage.
>>
>> -Tadge
>>
>> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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.
>>
>> Aaron
>>
>> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> The concept combined with the weak blocks system where miners commit
>>
>> to potential transaction inclusion with fractional difficulty blocks
>>
>> is possible. I'm not personally convinced that unconfirmed
>> transaction
>>
>> display in a wallet is worth the privacy trade-off. The user has
>> very
>>
>> little to gain from this knowledge until the txn is in a block.
>>
>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>>
>>> Hi
>>
>>>> We introduce several concepts that rework the lightweight Bitcoin
>>
>>>> client model in a manner which is secure, efficient and privacy
>>
>>>> compatible.
>>
>>>>
>>
>>>> The BFD can be used verbatim in replacement of BIP37, where the
>> filter
>>
>>>> can be cached between clients without needing to be recomputed.
>> It can
>>
>>>> also be used by normal pruned nodes to do re-scans locally of
>> their
>>
>>>> wallet without needing to have the block data available to scan,
>> or
>>
>>>> without reading the entire block chain from disk.
>>
>>> I started exploring the potential of BFD after this specification.
>>
>>>
>>
>>> What would be the preferred/recommended way to handle
>> 0-conf/mempool
>>
>>> filtering – if & once BDF would have been deployed (any type,
>>
>>> semi-trusted oracles or protocol-level/softfork)?
>>
>>>
>>
>>> From the user-experience perspective, this is probably pretty
>> important
>>
>>> (otherwise the experience will be that incoming funds can take
>> serval
>>
>>> minutes to hours until they appear).
>>
>>> Using BIP37 bloom filters just for mempool filtering would
>> obviously
>>
>>> result in the same unwanted privacy-setup.
>>
>>>
>>
>>> </jonas>
>>
>>>
>>
>>>
>>
>>> _______________________________________________
>>
>>> bitcoin-dev mailing list
>>
>>> bitcoin-dev@lists.linuxfoundation.org
>>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>
>> _______________________________________________
>>
>> bitcoin-dev mailing list
>>
>> bitcoin-dev@lists.linuxfoundation.org
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2] http://breadwallet.com
|
