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: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2695110EF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Feb 2016 02:36:46 +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 9300A155
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 17 Feb 2016 02:36:45 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id A6DC338A2305;
Wed, 17 Feb 2016 02:36:10 +0000 (UTC)
X-Hashcash: 1:25:160217:morcos@gmail.com::NSbc/sgm/lEDhnQq:af4r6
X-Hashcash: 1:25:160217:bitcoin-dev@lists.linuxfoundation.org::RDeabUIxaO4dDhor:dqzQ+
From: Luke Dashjr <luke@dashjr.org>
To: Alex Morcos <morcos@gmail.com>
Date: Wed, 17 Feb 2016 02:36:09 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; )
References: <CAPWm=eXi98cC0KP=5WayU05hezDFswrPe+vA58cTHvVLc80OzQ@mail.gmail.com>
<201602170046.17166.luke@dashjr.org>
<CAPWm=eVdMy0Fp_pGq6mpt1J-pH_zmA=ca9peM=pL=Gp-GyDBLw@mail.gmail.com>
In-Reply-To: <CAPWm=eVdMy0Fp_pGq6mpt1J-pH_zmA=ca9peM=pL=Gp-GyDBLw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602170236.09826.luke@dashjr.org>
X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD,URIBL_SBL autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 17 Feb 2016 02:36:46 -0000
On Wednesday, February 17, 2016 2:28:31 AM Alex Morcos wrote:
> On Tue, Feb 16, 2016 at 6:46 PM, Luke Dashjr <luke@dashjr.org> wrote:
> > On Tuesday, February 16, 2016 8:20:26 PM Alex Morcos via bitcoin-dev
wrote:
> > > # The feefilter message is defined as a message containing an int64_t
> >
> > where
> >
> > > pchCommand == "feefilter"
> >
> > What happened to extensibility? And why waste 64 bits for what is almost
> > certainly a small number?
>
> I thought that extensibility was already sufficient with the command string
> system. If we come up with a better version of the feefilter later we can
> just give it a different command name.
We shouldn't need a new protocol [extension] for every new policy. Obviously
this can't be perfectly flexible, but supporting different feerate definition
versions is trivial and obvious.
> > > # The fee filter is additive with a bloom filter for transactions so if
> > an
> > > SPV client were to load a bloom filter and send a feefilter message,
> > > transactions would only be relayed if they passed both filters.
> >
> > This seems to make feefilter entirely useless for wallets?
>
> I don't follow this comment? Transactions aren't synced with the wallet
> unless they are accepted into the mempool. Sending feefilter messages
> should not reduce the number of transactions that are accepted to the
> mempool.
In Core, they aren't (but Core never uses bloom filters anyway) - because
otherwise it would leak privacy. But light clients (particularly overlapping
with those that use bloom filters!) have no privacy in the first place, so
they have no reason to use this rule.
Luke
|
