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
|
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 66C83959
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 20:27:31 +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 C5384262
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 20:27:30 +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=1483474740; bh=EdNuZoi+Q7H8HnlqPClXvJ6cTweKwvG7Q5Yc5LUwH8Y=;
h=Date:From:To:Subject:In-Reply-To:References:From;
b=bWKA6//LXI6zpt7frT/CZOE2+VNYpZItQ1eHmpfEHhqD6QzdYINp354awBa7Z8Sxd
b/J31uE1oRT+VfdT6MeVAyLE6PQPa6mMbEXskRexWRU8lP79r8ZS+8nEfXk2MJCvtj
E+Aa1ZiKfmaH6NvxDTOGfy/Ddi+b606PL0m+9MuSRXpNxdkRr/9Q4yRH4Mgya6FhRe
0w9WupDXkoFKfj0UXQNoQFlNtFuU7Y/HCl+rJswsKK1YaGejnFtV94VKkcEIxVJJFY
80eKWQ/TO5KkxoFh9aYP9GaEj9c8ZbEFW/TBc7GNOyb5nnP3vlvQp4Y2QEqYimUtvg
bGzY6HUngrJjQ==
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 03 Jan 2017 12:18:59 -0800
From: bfd@cock.lu
To: Jonas Schnelli <dev@jonasschnelli.ch>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
Message-ID: <74aeb4760316b59a3db56c0d16d11f28@cock.lu>
X-Sender: bfd@cock.lu
User-Agent: Roundcube Webmail/1.2.3
X-Mailman-Approved-At: Tue, 03 Jan 2017 20:40:07 +0000
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: Tue, 03 Jan 2017 20:27:31 -0000
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
|
