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.

Replies (1)

Thanks for clarifying. I understand that the fee estimation uses past block data and there is an ability to self-correct with RBF/CPFP. If the concern is not about the initial estimate failing there is still a worse reaction time. If a node is blind to a large segment of the real mempool, wouldn't it be slower to detect a sudden spike in the fee market, potentially causing it to fall behind in a fee-bumping war? On the other points we are also left with the problem that the network communication is breaking down because more nodes are rejecting the very transactions that miners are confirming in blocks. Here is the problem visualized: "In early June we were requesting less than 10kB per block were we needed to request something (about 40-50% of blocks) on average. Currently, we are requesting close to 800kB of transactions on average for 70% (30% of the blocks need no requests) of the blocks." image from this research thread: