Policy: Reduce Default Max Mempool Size to 50 MB #20990

EDIT: I am now against this proposal too since it would cause fees to increase without the tx capacity increasing.

50 MB seems reasonable to me (Because most likely a transaction in the 51st MB won't be confirmed soon)

The mempool has an overhead (maybe 2x), so this will be less than 25 blocks (~250 minutes) worth of txs.

This doesn't affect mining pools' profits

If the whole network has a limit of 50MB and a wallet has no direct connection to a mining pool, there is no way to send a tx that would be accepted by a 3000MB mempool.

NACK, 50mb is too low IMHO

OK, how about 100 MB?

This doesn't affect mining pools' profits

If the whole network has a limit of 50MB and a wallet has no direct connection to a mining pool, there is no way to send a tx that would be accepted by a 3000MB mempool.

The scenario is this: The 50 MB mempool is not full, the user publishes a transaction, the tx is kicked out of the mempool, then the miner can still keep that tx in their mempool, or replace it with a higher fee one if a newer one is broadcast.

It is too easy to abuse and bypass the 14-day limit by re-pushing transactions

Your proposition does not help to get rid of the cause of the problem.

@prusnak It does, against a permanent stay in the mempool, if we rather not accept the tx to the mempool, we would be giving the user a second chance to transact with a higher fee.

Adding an nSequence bit with the meaning of "if the lock time has passed long since, the transaction shouldn't be considered standard and not relayed" would also equally work. (This sounds worse to me, since its more complex and can be used as an attack vector against 0-conf)

It's reasonably sized. It can accommodate high inflows of transactions. The idea is still very much to mine a block on average every 10 minutes. That hasn't changed. The number of daily transactions isn't exactly at an all time low. I agree that the fee structure is aging. I disagree that the solution would be to reject transactions. If anything that would be an incentive for miners to only pick up transactions with very high fees. The difficulty mechanism was always assuming a somewhat natural growth of hash power. We reached the point where the processing power is wasted because no better system has been engineered.

It's not an easy problem to solve. I'd like to help with it but I won't ever do it alone and the echo I've had from core devs seems to be "if it ain't broke don't fix it" (ironically the same reason why banks still use IBM mainframes). I digress. I think it's a bad idea, the limit would be hit nearly every day.

NACK, 50mb is too low.

300mb is reasonable for most hardware to run, if a user wants to lower it they can with in their config settings.

Closing for now due to controversy