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.The Bitcoin Developer mailing list discussed the "feefilter" message and its definition as a message containing an int64_t, which raised questions about extensibility. The use of different feerate definition versions was suggested to avoid the need for a new protocol extension for every new policy.Luke Dashjr questioned the usefulness of the message for wallets due to the fact that transactions would only be relayed if they passed both the fee filter and a bloom filter. However, Alex Morcos clarified that sending feefilter messages should not reduce the number of transactions accepted into the mempool. The discussion also highlighted the issue of privacy concerns with light clients using bloom filters.In this email exchange, Luke Dashjr questions the use of an int64_t datatype for the feefilter message in Bitcoin development. He argues that it is wasteful to allocate such a large number of bits for what will likely be a small number. Additionally, he questions the lack of extensibility in the current system.Alex Morcos defends his decision by stating that the command string system already provides sufficient extensibility and that a different command name can be given to a better version of feefilter if developed later. He also notes that the 8-byte size of the message is not a significant optimization issue given the low frequency of its use compared to ping traffic. Morcos also clarifies that the feefilter is additive with a bloom filter for transactions, meaning that transactions must pass both filters to be relayed.Dashjr questions the usefulness of this for wallets, but Morcos points out that sending feefilter messages should not affect the acceptance of transactions into the mempool. The email thread ends with no further resolution on the issue.In a Bitcoin developer forum post on February 16, 2016, Alex Morcos questioned the use of the feefilter message, which is defined as a message containing an int64_t where pchCommand == "feefilter". He asked about extensibility and why 64 bits would be used for what is likely a small number. Another user, Luke, pointed out that the fee filter is additive with a bloom filter for transactions, so if an SPV client loaded a bloom filter and sent a feefilter message, transactions would only be relayed if they passed both filters. Luke indicated that this seemed to make feefilter entirely useless for wallets.A proposal has been made to add a new optional peer-to-peer (p2p) message called "feefilter" that would help to reduce unnecessary network traffic. This message would inform peers of the minimum fee below which no transactions are accepted to a node's mempool, saving them from requesting transaction ids and saving the node from requesting transactions that are not in its recentRejects filter.The feefilter message is optional and can be ignored as a protocol rule, and there is also an option to turn off sending the messages within the implementation. The draft BIP text provides an abstract, motivation, specification, considerations, backward compatibility, and implementation details.The feefilter message is designed to instruct peers not to send inv's to a node for transactions with fees below the specified fee rate, and it is meant to filter transactions that are not accepted to a node's mempool, without adversely affecting the propagation efficiency of transactions across the network.There are privacy concerns related to deanonymizing a node by broadcasting identifying information about its mempool min fee, but these concerns are addressed by quantizing the filter value broadcast with a small amount of randomness and broadcasting messages to different peers at individually randomly distributed times.
Updated on: 2023-08-01T17:51:50.789054+00:00