From: Gregory Maxwell <greg@xiph•org>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message
Date: Wed, 17 Feb 2016 02:43:02 +0000 [thread overview]
Message-ID: <CAAS2fgR5uQbiXPFVa_NM_=1B2uM4GAPoF+RDrE32ENv6ODCrAw@mail.gmail.com> (raw)
In-Reply-To: <201602170046.17166.luke@dashjr.org>
On Wed, Feb 17, 2016 at 12:46 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.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?
I did think it might be interesting to do a priorityrate filter. but
since it seems no one is even working on adding an index for ancestor
priorityrate... or working on a space limited priority mempool... if
that extension would be needed it could just be a new "priorityfilt"
command.
> And why waste 64 bits for what is almost
> certainly a small number?
Technically fees per byte could be greater than 32 bits (e.g. a 9000
BTC fee is enough). Values are normally 64 bits already.
>> # 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 think your reasoning is that you want to learn of your own
transactions even if they don't meet the filter?
I'm not sure this reasoning plays out though-- regardless of what your
own feefilter is, if a tx has too low a rate for your peers to relay
it, they won't and you won't learn of it.
I might wave my hands at a use case for OR "I will relay very high fee
txn ... or my own"; but considering that performance/privacy disaster
that bloom filters are-- and that to relay third party txn at all you
need to be able to validate them (or will get yourself banned). Also,
if you really want the OR behavior you could make two connections...
the same cannot be said for and.
Maybe one argument I could add is that if we added a priorityrate
filter, that one would be an OR
prev parent reply other threads:[~2016-02-17 2:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 20:20 Alex Morcos
2016-02-17 0:46 ` Luke Dashjr
2016-02-17 2:28 ` Alex Morcos
2016-02-17 2:36 ` Luke Dashjr
2016-02-17 2:43 ` Gregory Maxwell [this message]
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='CAAS2fgR5uQbiXPFVa_NM_=1B2uM4GAPoF+RDrE32ENv6ODCrAw@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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