pull down to refresh
663 sats \ 4 replies \ @028559d218 19h \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
For what it's worth, to people who are far more influential...
There is a growing 'army' of folks who want to run more restrictive mempool policies to 'kill the spam'. Anti-ordinals, anti-memecoins, anti-BRCs etc... This is preached nonstop over and over, just do 'x' and you can stop the spam. "It's your memepool do X" etc etc.
What some of these "educators" don't explain however... is what you just said. About increasing latency, delay, bandwidth, speed at which blocks are relayed, miner centralization etc.
People are free to run whatever they want... but some of the "influencers" in the space only tell half the story or don't explain some of the downsides. It's like 'do this it's good' but without explaining why 'that' may not be a great idea. Thank you guys
good point
reply
Right! However, this is not a static situation as this is fully solveable with a relatively small amount of code: if people are truly serious about filtering, they could simply add a "purgatory" inside the mempool (or outside it, that doesn't matter) where all the crap lives that one does not want to relay or mine, but is still valid for (a) new txn inputs (where the new txns automatically end up in purgatory too unless the offending parent gets mined) and (b) compactblock reconstruction.
reply
wait, what are you talking about specifically? Is this a mempool policy? or something else?
my understanding is that a 'complete' solution does exist, the 'purifier' solution but of course it is a hard-fork.
reply