- My optimizer finds the cheapest way to run a home solar battery, which for a real home in Golden, Colorado, comes to $455.72 a year on top of the $971 its panels save. Sunlight, prices and household use come from public Department of Energy data, every day of the year is solved exactly, and you can run it in the browser.
- Six times I ran circuits on ibm_fez, an IBM quantum computer, 165 seconds of machine time in all, writing down my prediction before each run. The job IDs, dates and shot counts are in one table. The circuits were small cases, a few hours of the day rather than all 24. Across the project I wrote down 26 predictions before their runs, and 8 of them failed, each one listed next to its result in a second table.
- I found a way to ask the same question on 52 qubits instead of 117 with none of the money lost. On the machine the smaller version came back less damaged by noise, 0.30 against 0.37, and a second job with a control agreed. In the newest run the deeper circuit won two days running, which went against my prediction that one and two circuit layers would tie.
- Three things had to be right for the quantum method: an encoding that cannot hand back an illegal plan, a penalty weight matched to the prices, and a rule for keeping the right tuning. The encoding's guarantee appears to be new, stated narrowly, while the other two are known ideas whose cost I measured. I wrote down what is new and what is not in FINDINGS.md.
- There is no clever schedule to find, because 2,448 plans tie for cheapest and all they share is running the house off the battery from 5 to 9 PM. Since a battery only earns on what it can push out in those hours, doubling mine is worth $0.00 a year, and making it empty faster, 2 to 2.5 kWh an hour, is worth $101.07. The sizing rule is on its own page.
Self-directed, ecdsa.fail
- I reproduced the community's best circuit, validated it on all 9,024 test points, tried eleven ways to make it cheaper, and published that it could not be improved. Over the next three weeks the leaderboard moved 25 times, all from one automated searcher. After seven of my eleven claims stood and four failed, I kept the write-up as it was and marked it wrong at the top.
- Editing the circuit re-rolls the test it has to pass, so a circuit has no pass or fail, only a failure rate. Over 199 full benchmark runs I measured that about 1 in 850 million attempts comes back clean, roughly 500 years of my laptop per success. Competitors all pay that cost, which the score does not count. To afford the measuring I rebuilt the checker to run 9.2 times faster and checked that it matched the official one on all 199 runs, failure for failure.
- On August 23 the competition replaced its circuit outright, 22 percent off the score, so the measurements above describe a circuit that no longer runs. For the new one I built a filter that spots a failing candidate in milliseconds instead of the checker's twenty seconds, cutting the slow checks a success needs from about 87,000 to about 830. Its first measurements caught a search cost I had published, off by six to eight times, and the same day a submission disproved a second claim, both of which I corrected in the account of that day.
- I filed three findings in the competition repository, an issue and two pull requests (27, 28), one of them a benchmark bug that makes experiments look like they had no effect. My own seven-hour search covered 6.2 percent of what one success needs before the frontier moved past my target. These scores are a snapshot, and I am still trying.
- The math underneath is my favorite part. Adding two points on the curve is a straight line and a reflection, after which the answer lands back on the curve every time, a property called closure. Counting the roots of a cubic proves it and hands over the addition formula, whose one division is where nearly all of the attack circuit's cost hides. The full derivation is written out in algebra no harder than a quadratic.
High School Research Program, six weeks, summer 2026
- At a U.S. Department of Energy national laboratory I mapped where an optical oven puts its heat. The oven is a 750 W lamp at one focus of an ellipsoidal mirror, so everything it emits lands on the other, with no heating element and no contact.
- The scanning rig I built for the map is a thermocouple on three motors, which Python drives through a 26 by 21 grid of positions repeated at 13 heights, reading a temperature at each one and drawing the beam as a map.
- The map picked out the focus, which is where the sample went. Because the scan covered a 20 mm square at about 50 W with the probe peaking near 100 °C, the map fixes where the beam lands and its shape, not what it reaches at full power.
- An indium sample 5 mm across changed all over, so the hot spot is at least that wide. Indium melted at about 250 W of the lamp's 750. And the probe reads low, because it reflects away some of the light meant to heat it.
- I presented it as a poster on August 14, 2026. Although the poster shows one metal, indium, I melted two more, tin and zinc, at the same spot between sending it to print and presenting it. What came out is a working way to find the focus, a map of the beam, and three melt points, not yet a curve from power to temperature.
Check my work
- LESSONS.md collects the solar project's corrections in one file, with the numbers.
- I registered each solar study before it ran, which leaves the plan and the results as separate committed files, and the sweep refuses to run against an edited plan.
- The solar result runs in one command on data committed to the repository, no network and no API key:
python -m quantum_solar. - results.tsv logs each ECDSA benchmark run with the commit it was measured on.