Assume some changes have been made to how Bitcoin Core's mempool logic, such as:
- The size of the mempool can be capped.
- The node will prefer to keep the txns with the highest fee/size ratio.
- The node will choose not to accept/relay txns whose fee/size ratio makes their probability of eventually confirming low enough.
- The node will evict txns from its mempool with the lowest fee/size ratio if it receives new txns with a higher fee/size ratio and its mempool is already at max capacity.
In this situation a user can always send a txn that will be confirmed soon if they pay a high enough fee. The question is: can a user know how high of a fee they should pay? They can get a good sense of this by looking at previous blocks. If the lowest fees per block in the last 100 blocks have been around one cent, then the user knows that it's extremely risky to send a fee of one cent, and he should only do so if the txn is not urgent at all, and if he doesn't mind checking up on it later and possibly re-sending with a higher fee. If our user sees that a 5 cent fee is more than at least half of all txns have paid in each of the last 100 blocks, he can be extremely confident that he won't have to worry about slow confirmations with a 5 cent fee. Wallet software can do this analysis and present the user with some friendly UI allowing him to select his level of urgency. Full node wallets can additionally look at the state of their own mempool to help estimate fees. This is a very simplified description of fee estimation. Wallets can be a lot smarter than this.
Arguments that a fee market won't work assume that the user in question is trying as hard as he can to pay the absolute minimum fee that he has to pay to make it into a block. But by definition the fees at the minimum threshold must always be unreliable. If the user wants a fast transaction, his problem is solved entirely by selecting a fee that he knows is not on the threshold of what will be included in the next block.
Some who argue that a fee market won't work claim users will start by sending a very low fee tx, see that it isn't confirming, then send a slightly higher fee tx, see that it isn't confirming, bump the fee slightly again, etc. They claim this will cause what would normally be one tx to become 3 or 4 or maybe 10 txns and swamp the network and cause everyone to use more bandwidth than otherwise. Moreover, it is argued that the fee needed for confirmation will constantly be increasing as people keep bidding up fees higher and higher. There are at least two problems with this:
- It assumes that the fee market is not in equilibrium at the time the tx is being sent. Markets tend to get to equilibrium quickly.
- Nodes can let their peer nodes know what the minimum fee/size ratio is that they're willing to accept. It's not in a node's interest to send a tx to a peer if they know their peer will immediately reject it. It saves them both bandwidth to communicate their preferred thresholds beforehand. A node might see the same tx broadcast to them several times if their threshold is low enough, but if they're trying to conserve bandwidth they can adjust their threshold.