Discussion
How to exactly is having filters making it more difficult expensive to run nodes leading to centralization?
Sir, did you type this while driving? đ
What nostr:nprofile1qqs0w2xeumnsfq6cuuynpaw2vjcfwacdnzwvmp59flnp3mdfez3czpspzemhxue69uhhqatjwpkx2un9d3shjtnrdakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uyj2dm5 means is that Bitcoinâs current 80-byte OP_RETURN filter centralizes mining: big pools with private relay connections can bypass it, giving them exclusive access to lucrative data transactions. Smaller miners and public nodes are effectively left out.
I believe removing this filter too early will shift centralization elsewhere. Without consensus rules blocking off-curve pubkeys or proper fees for storage, weâll invite spammers to stuff data cheaply into the blockchain, bloating chain history and the UTXO set. That raises the costs of running full nodes, ultimately pushing validation into fewer hands and centralizing the network at a different layer.
Taking Bitcoinâs 80âbyteâŻOP_RETURN cap off is like removing the mesh from a windowâspam wonât vanish; it just blows straight in.
The line âeâmail is 90âŻ% owned by five companiesâ actually counts reading apps, not mailbox hosts. AppleâŻMail, for instance, only fetches messages that can live on any server. Hosting is more concentrated than it used to be. However, itâs no monopoly, and the plumbing remains highly federated: the Internet is still dotted with independent MX servers and live SMTP nodes. Deliverability is concentrated; the transport network is notâso eâmailâs path doesnât prove Bitcoin must centralise if a policy knob disappears.
Hashcash failed because SMTP lacks Bitcoinâs two brakes: an unforgeable fee token and a hard blockâspace ceiling. Spammers could mint proofâofâwork âstampsâ on hijacked PCs for almost nothing, while every Bitcoin transaction must burn real satoshis and bid for finite space. Remove the OP_RETURN cap and, when fees are low, jumbo payloads will bloat the chainâs permanent history; when costs rise, attackers will bury data in offâcurve pubkeys, inflating both history and the UTXO set unless those keys are made invalid.
Until consensus rejects offâcurve keys and the fee schedule fully prices storage (e.g., via a higher vbyte multiplier for data outputs), the 80âbyte limit is the least bad option. Lifting it now would swap a minerârelay concern for a permanent chain and UTXO bloat that every node would carry forever.