pull down to refresh
57 sats \ 6 replies \ @DarthCoin 21h \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
What will be the worst case scenario if users still could set their own limits for OP_RETURN?
Since transactions with larger OP_RETURN outputs or multiple OP_RETURN outputs are consensus valid, they will appear in blocks as long as they find their way to mining pools and mining pools choose to include them. Any nodes that don’t allow such transactions in their mempool will download them twice: once when the transaction is first offered to them by a peer, where they download it, evaluate it, and drop it due to their mempool policy, and then a second time when they receive the block announcement that includes the transaction.
Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.
Slower block propagation benefits larger mining pools by increasing the number of stale blocks and delaying other miners in switching to the new chaintip. Bigger miners disproportionally win over competing blocks and the block author doesn’t suffer from the propagation delay when a block is found.
reply
Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.
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
reply
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