Bitcoin Core v30.0 的争论其实还有点严重，甚至提及软分叉了，反正社区是大概分为两派的，主要是 Adam 和 Luke 吵架。差不多有这么些观点吧： 1️⃣ Core 开发者认为 v30 通过修改 op_return 中继默认值修复了「激励错误」，并指出之前的 80 字节策略在中继层已事实性失效超过一年。 他们表示此更改减少了使用替代编码（例如大量 32B 假公钥行）作为某些二层锚定的动机，并强调 op_return 的链上容量约为 inscriptions 的四分之一。 支持者强调这只是策略/默认值调整而非共识规则变动，许多中继已经在运行新的默认设置，网络在新参数下仍在正常运作。 2️⃣ 有些节点运营者和社区成员认为 Core 在合并前应寻求妥协（有人建议将默认恢复到≈160–166 字节）。部分社区成员主张通过分叉或 UASF 强制规则变更，而另一些人警告称临时紧急软分叉或链分裂风险极高，呼吁更好的对话。 具体的缓和建议包括在 30.1 版本中恢复较小的默认值。 3️⃣ 讨论中提出了多条技术路线：有人支持通过 BIP‑444 或采用「running knots」作为替代客户端路径，也有人提出以临时或紧急软分叉改变行为。 多位参与者警告称软分叉「高度风险」且难以达成共识，并指出「running knots」被描述为「中度风险」，据称会引入约 4 万行较少审查的代码。 另有观点指出 BIP‑444 已按流程分配，同时出现了用于量化分叉概率的元讨论（包括预测市场）。 总体权衡是在争议性的 Core 合并、具争议的软分叉，或迁移到存在工程与审查风险的替代实现之间做出选择。 4️⃣ 法律与内容安全担忧同时存在：若干用户警告称更大的连续 op_return 字段会增加 CSAM 或其他非法内容被永久写入链上的可能性，并可能引发监管介入。 也有人反驳称通过共识阻止数据是不可行的，因为编码可以分散在多个字段（假公钥、inscriptions、多个 pushdata）中，且链上文件存储在经济上并不高效。 建议的缓解措施包括由运营者采用可选的节点策略、修剪或检查点，而非通过全网共识变更，但有人质疑这些措施能否充足降低法律风险。 讨论还涉及将 op_return 通过共识限制是否真能解决法律风险，或只是把策略问题移入共识层而无法阻止其他编码手段。(Zhixiong Pan)