Author: Gregory Maxwell 2016-02-17 02:43:02
Published on: 2016-02-17T02:43:02+00:00
In a bitcoin-dev mailing list thread, developers discussed the feefilter message and its usefulness. The message is defined as a message containing an int64_t where pchCommand == "feefilter". Luke Dashjr questioned the lack of extensibility in the message, suggesting that a priorityrate filter could be interesting. However, as there are currently no plans to add an index for ancestor priority rate or create a space-limited priority mempool, a new "priorityfilt" command could be added if needed. Alex Morcos suggested the feefilter message could be useless for wallets because it is additive with a bloom filter for transactions. Transactions would only be relayed if they passed both filters, making it difficult for SPV clients to learn about their own transactions. Dashjr argued that regardless of a user's feefilter, if a transaction has too low of a rate for peers to relay, users won't learn of it. He mentioned a use case for an OR behavior where he would relay very high fee transactions or his own. However, due to the privacy disaster of bloom filters and the need for validation to relay third-party transactions, it would not be practical. Dashjr suggested that a priorityrate filter could be used as an OR instead.
Updated on: 2023-05-19T23:11:31.344376+00:00