pull down to refresh

I don't think this is a good idea.
There's no reason to have tons of transactions floating around that aren't going to be mined in a reasonable amount of time. Better that users broadcast transactions that make financial sense, and use up network bandwidth for those transactions only. That works best when the min fee rate actually matches what is going to be mined in a reasonable amount of time, and the min fee increases appropriately.
Also, the rational given re: transaction expiration doesn't make any sense. The length of time a transaction can stay around in the mempool isn't directly related to the size of the mempool at all; the mempool is not a first-in-first-out (FIFO) queue. It's a priority system where whomever pays the most, gets served the fastest. The idea that "300MB is 2 days of transactions" is completely wrong.
Of course, on an individual level, you can use whatever mempool size you want. You'll just waste a bit of bandwidth compared to using a size that your peers are using.
(When I get home I need to login to GitHub and add these comments to the pull-reqs...)
reply
aren't going to be mined in a reasonable amount of time
Question is what is reasonable amount of time here. 300 MB with segwit is potentially less than 24h. Main impact IMO is that tx below the drop feerate for most of the nodes are simple to replace, without fee bumping.
reply
What are your calculations for "less than 24hr"?
You can't do that math by assuming transactions are processed first-in-first-out. That's not how the mempool works.
I created a transaction a few days ago at 1sat/vbyte myself. It's still waiting, because obviously, why wouldn't it? The fee market has been such that it's never been worth mining a 1sat/vbyte tx.
reply
I meant assuming no new transactions comes in, what could fit into mined blocks next 24h.
reply
Exactly my point: assuming no new transactions come in is ridiculous. New transactions always come in. And in circumstances where there's been high enough demand to reach the mempool limit, it's even more likely that new transactions will be coming in!
reply
5 days uncomfirmed with a 1sat/vbyte, to myself so no worries, more of an experiment. Just bumped the fee to 3sat/vbyte and the default rate went up more for the current block. I'm in no rush. But it is fun watching all this. Happy for the miners during the current market.
Also all this is showing me how important Lightning is for instant and low fee transactions. I got too accustomed to empty mempool layer one transactions. Like all things. This too shall pass.
reply
и смысл? если на своём пк ты можешь поставить хоть 100 терабайт...
reply
reply
Big Mempool War commencing
reply
Get rid of ordinals stupidity, “problem” solved
reply
Guess you meant Inscriptions, as Ordinals is just interpretation of blockchain data, they don't consume any space in mempool or blockchain.
Well, you can't. People are free to use Bitcoin however they want, even for stupid things, if they are ready to pay for it.
reply
Yes I meant inscriptions. So you’re saying one fundamental change to the code is doable, but another fundamental change can’t be done?
reply
Mempool size limits and actually any mempool policies aren't consensus rules. You are free to change these for your node however you want. But what can go into mined blocks is consensus.
reply
It might reduce bandwidth consumption because if ur limit is 300mb and someone else is 900mb then u might recieve a low fee transaction but it gets discarded caus the mempool fills up but then mempool drops again and you recieve the transaction again. But rather than changing the default I may support giving the user a warning and to consider increasing the default if it gets full for more than a week or something unless i am missing something.
reply