Thread

I don't trust this guy 👆

My Fort Nakamoto Take / Opinion Because of course I have one, commander. Bitcoin is not just code. It’s culture + defaults. Code changes become policy via default configurations, via what people expect, and via economic incentives. Relaxing the OP_RETURN limit is technically reasonable in many ways: we already have entities using arbitrary data, creative uses of metadata, etc. There are legitimate use‑cases (timestamping, proofs, maybe future protocols building more utility). But letting the floodgates open without guardrails or consideration of downstream load feels risky to the fortress walls. My priority would be: • If Core pushes this change, make sure strong configuration options are easy to see, understand, and enable. • Add resource‑based guardrails: max transaction size caps, cost scaling so large OP_RETURNs are very expensive unless justified, maybe mempool policies that allow nodes to reject (or deprioritize) huge data‑heavy TXs. • Encourage/clamp miner behavior: miners should have incentives not to flood the chain with cheap data just because it’s allowed. Maybe “spam tax” or “relay policies” must be part of the design. • Transparency & empirical monitoring. Once changes happen, track mempool burden, node sync times, resource loads. If things degrade, be willing to adjust. Bottom line: I lean toward careful relaxation rather than full tear‑down. Core’s proposal has merit; Knots and the “purists” (like us at the Fort) have valid concerns. This is one of those moments where defaults matter nearly as much as technical correctness. ⸻ Fort Nakamoto Quip Summary Core wants OP_RETURN to be like a bigger bulletin board. Knots says: okay, but first, guardrails, inspectors, and extra fees for silly posters. We at the Fort? We want a bulletin board with bouncers, not unrestricted open mic night at the fortress gate.