Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical. Not relaying is the same as not running that node for those transactions, does't stop anyone else. The filtering node slows down it's own to verify blocks - will be later to reach the tip, will waste hashrate in that time if mining. Only the fastest route counts so even a supermajority would not be signficant.

Replies (1)

Super Testnet's avatar
Super Testnet 3 months ago
> Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical I do not understand this criticism. Neither Knots nor Core looks *only* at the mempool to estimate fees. Partly as a result of this, the scenario where a wallet based on Knots would give a fee estimate that "wouldn't work" seems absurd: (1) the total weight of spam transactions in the mempool would have to *suddenly* increase (2) without a corresponding, similar increase in competition from "normal" (non-spammy) transactions (3) to a point where the non-spammy transactions only show fees at level X (4) but the real feerate is actually at level Y (5) and Y is so much larger than X that X won't work. But even that's not enough, for the following reason: As an example of a wallet with a critical need to get a transaction confirmed in a certain time frame, consider a lightning node. These have to be prepared to use RBF or CPFP to bump their transactions if a justice transaction is called for, because they must "go through" in a certain time frame. (E.g. see here: https://docs.lightning.engineering/lightning-network-tools/lnd/sweeper). Since Knots and Core both look at "recent blocks" to figure out what the current feerates are, and not just the mempool, this means the above scenario -- with the sudden increase in spam fees with several other conditions attached -- will only cause the wallet to fail to get its transaction confirmed if the scenario *repeats* as each subsequent block comes out, such that the additional fee information provided by block K+1 is already out of date when Knots tries to estimate fees again at the prompting of whatever wallet wants to use RBF or CPFP to get its transaction confirmed. Given the absurdity of such a situation playing out in the real world, it seems equally absurd to use this as a legitimate criticism of Knots. Even in critical applications, your fee estimator does not need a *precisely accurate* mempool. If bitcoin required that, it would be a broken system, because the mempool is intentionally not consensus critical.