You'rre right that CVEs aren't normative. They identify a claimed vulnerability. They don't magically settle whether something _actually is one_ That's exactly my point. When the same person who: - reinterprets a long-standing policy, - broadens its scope beyond its original definition, - classifies behavior as a vulnerability, - assigns a CVE, - and ships the mitigation …that does not transform a policy disagreement into an objective security flaw. It just means one implementation chose to treat it as such. And knots fixed it so you may commence and run it. And on datacarriersize apparently changing: the historical distinction absolutely matters. It applies to a specific relay policy OP_RETURN followed by a PUSH. Retroactively expanding the interpretation and then saying "see, it applied more broadly" is circular reasoning. You can't redefine the scope and then claim the redefinition proves the original intent. If one developer widens the meaning of a flag and calls anything outside that widened meaning a vulnerability, that does not make it true. It makes it their implementation choice. In a distributed system every implementation can mitigate however they want. Calling something a vulnerability doesn't elevate a policy preference into a universal security defect. Consensus rules are normative. ✅ Policy rules are local. ✅ CVE labels are descriptive. ✅ Blurring those lines is a problem here.