Debate around Bitcoin Core v30.0 is actually pretty intense, even bringing up soft forks. Anyway, the community seems split into two camps, mainly revolving around Adam and Luke arguing. Here are roughly the main points: 1️⃣ Core developers believe v30 fixes the 'incentive bug' by modifying the default value for op_return relay and point out that the previous 80-byte policy has effectively been invalid at the relay layer for over a year. They argue this change reduces the motivation to use alternative encodings (like large 32B fake public key rows) for certain Layer 2 anchoring and emphasize that the on-chain capacity of op_return is about one-fourth of inscriptions. Supporters stress this is merely a policy/default adjustment, not a consensus rule change, and many relays are already running the new default settings, with the network functioning normally under the new parameters. 2️⃣ Some node operators and community members think Core should seek compromise before merging (some suggest restoring the default to ≈160–166 bytes). Certain community members advocate for rule changes via forks or AmericaF, while others warn that temporary emergency soft forks or chain splits carry extremely high risks, calling for better dialogue. Specific compromise suggestions include restoring smaller default values in version 30.1. 3️⃣ Several technical routes were proposed during the discussion: some support using BIP‑444 or adopting 'running knots' as an alternative client path, while others suggest temporary or emergency soft forks to change behavior. Multiple participants warn that soft forks are 'high risk' and difficult to achieve consensus on, while 'running knots' are described as 'moderate risk,' reportedly introducing about 40,000 lines of less-reviewed code. Another viewpoint notes that BIP‑444 has been allocated according to process, alongside meta-discussions on quantifying fork probabilities (including prediction markets). The overall trade-off is between the controversial Core merge, contentious soft forks, or migrating to alternative implementations with engineering and review risks. 4️⃣ Legal and content safety concerns are also present: several users warn that larger consecutive op_return fields increase the likelihood of CSAM or other illegal content being permanently written onto the chain, potentially triggering regulatory intervention. Others counter that blocking data via consensus is infeasible since encoding can be spread across multiple fields (fake public keys, inscriptions, multiple pushdata), and on-chain file storage is not economically efficient. Suggested mitigation measures include operators adopting optional node policies, pruning, or checkpointing rather than full network consensus changes, though some question whether these measures can sufficiently reduce legal risks. The discussion also touches on whether limiting op_return via consensus truly addresses legal risks or merely shifts policy issues into the consensus layer without preventing other encoding methods.