Re: [bitcoin-dev] [BIP Proposal] New "feefilter" p2p message

[Gregory Maxwell <greg@xiph.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