So you think you've solved an open problem

Every famous open problem has been “solved” thousands of times, almost always incorrectly, usually by capable and sincere people. That's not a knock on you — it's a prior you should hold about yourself. The correct starting belief is: this is probably wrong, and my job is to find out how. Nothing below works if you're defending the proof instead of attacking it.

The good news is that the same skepticism that makes this humbling makes it fast. Most incorrect proofs die to a single small check. You can run most of them yourself in an afternoon, before you've told a soul.

Before anything else, three questions that end most claimed proofs immediately:

• Does it survive one small case?Take the smallest nontrivial instance and run your argument on it by hand. If it's a “for all n” claim, try n = 1, 2, 3 explicitly. Proofs that are secretly wrong often can't even be executed on a concrete input.
• Where exactly does each hypothesis get used?Point at the line. If you can drop a hypothesis and the argument still “works,” you've either proved something stronger (extraordinary — and probably wrong) or you have a gap.
• Does your method also prove something false?This is the single most powerful test. If the same argument, unchanged, would prove a statement known to be false (a nearby variant, a case with a known counterexample), the argument is broken — no need to find where. Math Lab's own Collatz and DGGpages are built around exactly these “it would prove too much” boundaries.

This is the heart of it, and where this site lives. If any part of your claim is concrete — a bound, an identity, a sequence, a specific construction — a computer can check it in exact arithmetic in minutes. Do this before you trust a single hand calculation.

• Wolfram Alpha — fastest first pass: evaluate your expressions, test an identity symbolically, factor, check a limit, plot. If your claim disagrees with Wolfram Alpha on a concrete input, stop and find out why.
• A computer-algebra system for the real work. SageMath (free; run it in the browser on CoCalc), PARI/GP for number theory, or SymPy / mpmath in Python. Use exact integers / rationals, never floating point, for any claim about exactness — floating-point “equality” has fooled a lot of people.
• The OEIS— if your work produces a sequence of numbers, paste the first terms in. Odds are it's already there, with references telling you what's known, what it's connected to, and sometimes that your “new” result is classical.
• Write the verifier, not the demo.Don't code something that shows your idea working on the case you like; code something that searches for the case that breaks it, exhaustively, in exact arithmetic. That's the standard every tackled problem here is held to — e.g. the DGG counterexample ships an exhaustive exact-integer checker over all routings, not a happy-path demo.

Spend an honest hour as the enemy of your own theorem. Push it to the extremal and boundary cases: the smallest, the largest, the degenerate, the tie, the empty set, n = 0 and n = 1, the case where two things you assumed distinct coincide. Conjectures and proofs alike tend to die at the edges, not the middle.

If your result is a construction(“here is an object with property X”), verify the object independently of how you built it — rebuild it from its definition and check every property from scratch, the way a referee would, not the way its author would.

Large language models are genuinely useful here — but only if you use them as flaw-finders, not judges. Prompt them against you:

• “Here is a proof of X. Find the single weakeststep and explain precisely why it might not hold. Do not tell me it looks correct.”
• Ask more than one — Claude, ChatGPT, Gemini — and make each try to refute the claim, construct a counterexample, and check a specific lemma in isolation.
• Have a model translate your argument into precise definitions. If it can't restate a step without inventing an assumption, that step is the gap.

Read the precise statementof the problem from a primary source, not a paraphrase — an enormous fraction of claimed solutions actually solve a different, easier, or already-known statement. Then find out what's already been done:

• arXiv and Google Scholar for preprints and papers; zbMATH Open (free) for reviewed literature.
• Learn the known partial results and barriers. If a result says “no proof of this kind can work” (a known obstruction, a relativization/natural-proofs-style barrier, a proven bound your claim would beat), your approach has to explain how it gets past that — or it doesn't work.
• Check whether your key lemma is a known openproblem in disguise. Sometimes the “easy step” is the whole difficulty.

If your proof is correct, it can be checked by a machine that has no interest in being polite to you. A formal proof in Lean (mathlib), Rocq (Coq), or Isabelleis the end of the argument: the proof assistant accepts it or it doesn't, and it will not accept a gap.

This is hard and it's supposed to be — the difficulty is exactly the rigor you want. Even formalizing the statementand the key lemma is clarifying; people routinely discover, while formalizing, that a step they were sure of doesn't actually hold. The Lean Zulip community is welcoming to newcomers with a specific, precise goal.

A checklist of the classic failure modes. Read it looking for yourself:

• Using the conclusion.Somewhere the thing you're proving is quietly assumed. The most common and hardest-to-see error.
• Division by something that can be zero, or taking a root/inverse/log of a quantity that isn't guaranteed positive/nonzero.
• “Without loss of generality” that loses generality— a symmetry or normalization that isn't actually available.
• Swapping limits, sums, or quantifiers (∀∃ vs ∃∀; interchanging limit and integral/sum without justification).
• Induction with a broken base case or a step that needs the very thing being proved.
• Finite ⇒ infinite. A pattern holding for all checked n, or a property of every finite stage, asserted for the infinite/limit object with no argument.
• “Almost all” ≠ “all.” A density/measure/probabilistic statement quietly upgraded to a universal one. (This exact distinction is why the Collatz page is careful to say Tao proved almost all orbits behave — not all.)
• An off-by-one, a sign, or a boundary casethat the “obvious” step skipped.

Once it has survived the checks above — and only then — put it in front of people, in the venues built for it:

• MathOverflow for research-level questions, Math StackExchange for everything else. Ask about the weakest stepas a focused question — not “is my proof of the Riemann Hypothesis correct” (that gets closed), but a precise, self-contained question about the specific lemma you're least sure of.
• Write for a skeptical reader. State the theorem precisely, define your terms, make it self-contained, and be honest about the gaps — flagging your own weak step is the single fastest way to get a serious person to engage.
• Don't lead with the claim.A document titled “PROOF OF [famous problem]” emailed to an expert is almost never read. A crisp question about one lemma, from someone visibly doing the work, often is.

If your result has passed the computational checks, the adversarial review, the literature, ideally a formalization, and knowledgeable humans haven't broken it — now you handle it like a result:

• Timestamp it. Post a preprint to arXiv (or a repository with a permanent DOI). That establishes priority with a public date.
• Submit to a peer-reviewed journal.Peer review is slow and adversarial by design — that's the feature. A correct result survives it.
• Keep every version and every check. The trail of exactly what you verified, and how, is part of the result.

If it's one of the problems tracked here, we'll take it head-on the way we took the DGG / Goemans cost conjecture: reproduce the claim in an exact-integer machine verifier and try to break it, honestly, with the result — proof, counterexample, or “dies at this step” — logged on the record. Dead ends are results too.

Use the Submit / feedback button in the sidebar to send it over (it reaches the lab directly), or — the durable path — open a pull request or issue on GitHubwith your statement and, if you have one, your verifier code. Precise statement, honest about the gaps, and a concrete case we can run: that's all we ask.