pull down to refresh
423 sats \ 0 replies \ @Murch 10h \ on: Powerful arguments for the 'meaning' of Bitcoin - What is going on? bitcoin
It takes about 10% of nodes accepting a transaction for it to be reliably relayed to miners.
A minority of nodes with more restrictive mempool policies is mostly detrimental to themselves. They are missing transactions from the compact block relay and therefore receive blocks more slowly, have an incomplete mempool for feerate estimation, and presumably slightly increased traffic with their peers, and if they are mining, they pick from a smaller pool of eligible transactions, therefore earning less fees (although fees are currently anyway a vanishing portion of the overall block reward).
While I care not for the whole frog picture on the blockchain thing, it feels to me like a "cut off your nose to spite your face" reaction to run a node with such a configuration.
OP_RETURNs are less harmful than other ways of storing data in the blockchain. Storing data in the blockchain is a millions of dollars business. It’s going to happen despite the noseless zealots, if only because the nodes run by frog picture enthusiasts would be configured to forward them. We are already seeing bigger OP_RETURN outputs in blocks.
The way I see it, we can either have people build out ways to submit transactions directly to mining pools, depriving the rest of the network from having full information and benefiting disproportionally the largest miners, or we can loosen the limits to at least keep the mempool mostly complete, and prevent further incentives to centralize mining.
Anyway, putting data into OP_RETURN outputs is only cheaper than inscriptions for payloads smaller than 143 bytes.
So, if we take a step back and soberly look at the situation, it seems quixotic and detrimental to keep the OP_RETURN limits in place.