Some advocate for increasing or removing the OP_RETURN size limit to support current data storage use cases, Layer 2 solutions, and reduce dependence on less efficient methods like Taproot outputs. They argue it’s a practical response to growing demand and aligns with Bitcoin’s design, since OP_RETURN data is prunable and doesn’t add to the UTXO set.

Others worry about blockchain bloat, potential security concerns, and a drift away from Bitcoin’s core use as a monetary ledger. The debate is ongoing, with no consensus yet among Bitcoin developers.

It’s a bit of a catch 22: nobody wants more spam or mission creep, but people are already using Bitcoin for other purposes. Ignoring that use either leads to UTXO bloat or forces developers to find more prunable alternatives; each with trade-offs and unknown consequences.

Bitcoin can run efficiently on multiple clients as long as they follow the same consensus rules and are well maintained. This supports decentralization and resilience. However, the risk of forks increases when clients diverge or aren’t well tested. Historical forks like Bitcoin Cash were mainly ideological, but poor coordination between clients can make technical disagreements worse. Bitcoin’s slow upgrade cycle and the dominance of Bitcoin Core reduce these risks, but they also limit diversity.

To me, Bitcoin has always been about coordination over conflict. It encourages building rather than destroying. The debate between Knots and Core isn’t a threat…it’s innovation. Both sides have valid points. Bitcoin has always improved through trial and error. If either side spots and fixes a problem, Bitcoin benefits in the long run.