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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 04384A95
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jul 2019 19:20:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8ECAAFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jul 2019 19:20:00 +0000 (UTC)
Received: from ishibashi.lan (adsl-67-34-245-3.asm.bellsouth.net [67.34.245.3])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id EEAC338A0D8F;
Sat, 27 Jul 2019 19:19:51 +0000 (UTC)
X-Hashcash: 1:25:190727:bitcoin-dev@lists.linuxfoundation.org::FAbu+jQtD8/hanji:67s4
X-Hashcash: 1:25:190727:andreas@schildbach.de::uoEKTpS=TwQeCD7A:k6xw
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Andreas Schildbach <andreas@schildbach.de>
Date: Sat, 27 Jul 2019 19:19:49 +0000
User-Agent: KMail/1.9.10
References: <59fad2b6-9b15-ffec-116e-91d27ce29f80@mattcorallo.com>
<qh2qj1$7sg4$1@blaine.gmane.org> <qh76ln$41ag$1@blaine.gmane.org>
In-Reply-To: <qh76ln$41ag$1@blaine.gmane.org>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201907271919.49999.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 27 Jul 2019 20:17:43 +0000
Subject: Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by
default
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: Sat, 27 Jul 2019 19:20:01 -0000
On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote:
> 3) Afaik, it enforces/encourages address re-use. This stems from the
> fact that the server decides on the filter and in particular on the
> false positive rate. On wallets with many addresses, a hardcoded filter
> will be too blurry and thus each block will be matched. So wallets that
> follow the "one address per incoming payment" pattern (e.g. HD wallets)
> at some point will be forced to wrap their key chains back to the
> beginning. If I'm wrong on this one please let me know.
BTW, you are indeed wrong on this. You don't need to match every single
address the wallet has ever used, only outstanding addresses that haven't
been paid. ;)
Luke
|
