public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: Alex Morcos <morcos@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message
Date: Wed, 17 Feb 2016 02:36:09 +0000	[thread overview]
Message-ID: <201602170236.09826.luke@dashjr.org> (raw)
In-Reply-To: <CAPWm=eVdMy0Fp_pGq6mpt1J-pH_zmA=ca9peM=pL=Gp-GyDBLw@mail.gmail.com>

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


  reply	other threads:[~2016-02-17  2:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 20:20 [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message Alex Morcos
2016-02-17  0:46 ` Luke Dashjr
2016-02-17  2:28   ` Alex Morcos
2016-02-17  2:36     ` Luke Dashjr [this message]
2016-02-17  2:43   ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201602170236.09826.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=morcos@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox