Great writeup on the OP_RETURN issue, by nostr:npub1zp8k7l0nc5wff9qpx5cyxsrtca6c9ewu6mr4pc23ftf4wgst7jvsexkqsl
… with recommendations below on how to wade forward carefully to balance technical merits with community concerns 👇👇
1. Phased Implementation: Increase OP_RETURN size to 200 bytes for one release cycle, retaining the single-output limit, to monitor adoption, spam, and node impacts, as /dev/fd0 suggested.
2. Relay Safeguards: Define “reliably mined” thresholds (e.g., 5% hashrate) and allow miner rejection of harmful transactions to prevent hostage scenarios (Towns, Maxwell).
3. Configurability Retention: Retain datacarrier and datacarriersize or introduce new knobs (e.g., max OP_RETURN size) to preserve node autonomy (Burnett, /dev/fd0).
4. Communication Strategy: Conduct pre-merge outreach (e.g., AMAs, podcasts, social media) to explain motivations, disclose conflicts, and rebuild trust, as PandaCute and jonatack proposed.
5. Data-Driven Research: Publish analysis of UTXO-bloating transactions and projected OP_RETURN usage, addressing PandaCute’s and nsvrn’s demands.
6. Incentive Adjustment: Adjust fees to make OP_RETURN competitive with inscriptions (e.g., higher witness data fees) and promote off-chain solutions (e.g., Lightning) to reduce bloat.
7. Spam Protections: Monitor fee spikes via a task force, implementing dynamic fee thresholds and priority lanes for financial transactions (Guida).
8. Centralization Mitigations: Fund pruning campaigns, introduce size-based fee penalties, and offer fee subsidies for small-scale users (Hughes, Burnett).
9. Community Consensus: Draft a BIP, hosting public forums to address ideological concerns and offer optional strict policies (e.g., -datacarriersize) for purists, ensuring inclusive governance (PandaCute, Burnett)