{"id":7030,"job_id":13839,"problem_id":6,"lane_id":33,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Self-match measure: vary-M7 step-sharing does not beat generic full-round search; production cells overlapped 9B on a nonce slip\n\nJob 13839, measure, self-match. Improvement claim: none. Best\ncandidate reached score 8, below the 13 floor, so nothing goes to the\nresults page.\n\n## Hypothesis\n\nThe first digest word is fully determined after MD5 step 60: the A\nregister is last written at step 60 (round 4 writes A at steps 48, 52,\n56, 60), while steps 61-63 write D, C, B. So a first-word filter needs\nonly steps 7-60 after hoisting steps 0-6 for a fixed M0-M6 base, and\nthe vary-M7 arm (vary only the last 4 candidate chars, message word\nm7, first used at step 7) should be cheaper per candidate than generic\nfull-round search. The binary's own selftest confirms the structural\nfact: h0 via steps 7-60 equals the full-MD5 reference (1110db54) for\nthe score-12 fixture. This job tests whether that fact buys throughput\non this machine.\n\n## Experiment and result\n\nSame-machine head-to-head, same 2B candidate range, one core per arm,\nsame load: vary-M7 30.36 M/s, full-round generic 31.21 M/s. Both arms\nfound the identical best-progression hits and the identical best\ncandidate (03cd888dc0117b50da6d1b6b59190342, score 7), which cross\nvalidates the vary-M7 implementation against the generic one. The\nthroughput hypothesis is refuted as stated: the step-sharing arm is\nnot measurably cheaper per candidate than full-round search here, the\n2.8% gap is within run-to-run noise and favors the generic arm. The\nhoisted steps 0-6 and the 4-step early exit are too small a fraction\nof the per-candidate work to show up at this build and load. Vary-M7\ntallies on the bench range were 8/0/0 for scores >= 7/8/9 against\nuniform 7.45/0.47/0.03, right on uniform.\n\n## Counted cells and the nonce slip\n\nTwo 10B vary-M7 counted cells were run, one core each: cell A2 from\n13906500000000 (30.27 M/s, best 8, tallies 38/2/0) and cell B2 from\n13907500000000 (30.30 M/s, best 8, tallies 38/2/0). The B2 start is\nonly 1B past the A2 start, not 10B: adding 10B to 13906500000000\ngives 13916500000000, and I wrote 13907500000000 by misplacing a\nzero. The two cells therefore overlap on 9B candidates, confirmed by\nrecomputing the shared score-8 candidate's batch (212254317) in both\ncells' batch ranges with a probe built from the searcher's own base\nderivation. The per-cell tallies must not be summed: the union is\n11B fresh candidates, not 20B. Fresh counted this cycle is 13B (the\n2B bench range plus the 11B union). The tally9-era counted total is\nnow about 206.13B (was about 193.13B), tally9 count unchanged at 1\nagainst about 3.00 expected. Next disjoint start nonce is\n13917500000000. Best candidate overall is\n03862271fbadf681c92a1391b9f434ee, score 8, hashlib-verified; all 37\nunique best-progression hits across the bench and both cells were\nhashlib-verified, 0 mismatches.\n\nA VM reset mid-cycle killed the first attempt at these cells at about\n60 s in; the partial tallies from the killed cells (about 1.8B each,\nbest 7) are not counted, and the relaunched cells start past the\nfurthest point the killed cells could have reached.\n\n## What this means\n\nThe track's CPU baseline is re-labeled, not broken: vary-M7 enumeration\nstays a valid uniform sampler (tallies stay uniform), but it carries no\nmeasured throughput advantage over generic search on this hardware.\nThe nonce slip cost 9B of double-counted compute this cycle and is\ncaught here by the identical best candidate and identical done-line\ntallies, not hidden: the counted total above uses the 11B union only.\nThe next cheap probe is the step-61 second-word gate (recorded-only\npremises 3246/3244), which would filter on 10 hex chars after step 61\ninstead of 8 after step 60; whether that buys anything is unmeasured.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-11-06T13:47:53.960Z","repo_url":null,"commit":null,"cites":null,"tokens":{"log":"summary","input":0,"models":{},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":[]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"# Recipe\n\nTo repeat, on two cores:\n\n1. Rebuild the tally9 binary from the self-match tally9 source with\n   gcc -O3 -march=znver4 -mtune=znver4; run its selftest (expect\n   fixture 12, SELFTEST PASS). Do the same for the full-round generic\n   binary.\n2. Head-to-head: run both binaries on the same 2B range, one core\n   each, simultaneous. Compare M/s and best-progression hits; identical\n   hits cross-validate the vary-M7 implementation.\n3. Production cells: verify the next disjoint start nonce from the\n   prior cell's done line, then ADD the cell size in full (10B to\n   13906500000000 is 13916500000000, not 13907500000000) before\n   writing the second start. Check the batch ranges do not overlap:\n   batch = nonce >> 16, and the ranges must be disjoint.\n4. If two done lines ever show the same best candidate, stop and\n   recompute the shared candidate's batch in both ranges before\n   counting anything.\n5. Compare tallies against N x 16^-k for score >= k, k = 7, 8, 9.\n6. Verify every best-progression hit with hashlib from the logged\n   candidate string before filing.\n7. Next disjoint start after this cycle is 13917500000000.","verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":"high","also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":null,"research_route_id":null,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":"2026-11-06T13:47:53.960Z","department_id":null,"run_id":null,"triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"paper_exposition":null,"research_evidence":null,"transcript_mode":"summary","known_work":null,"work_disposition":null,"applicability_assessment":null,"negative_result":null,"first_indexed_at":null,"index_held_at":null,"index_ok":null,"index_reason":null,"handle":"sundayweaver","job_brief":"Study how a candidate's 32 ASCII bytes flow through the 64 steps into the first digest characters, and use what you learn to reach a longer matching prefix. Ideas to test: which message words the first output word depends on most, fixing a prefix and solving for the rest, early-exit tests on the first output word, meet-in-the-middle on the step function. Start from the algorithm, not the search. Read the track's state of the art in this brief (the fastest known way per machine, what worked, the dead ends) and research/QUESTIONS.md, then state one hypothesis about MD5's structure that would make this track cheaper than generic search, and why you expect it. Test it with the smallest experiment that could refute it, against a measured baseline on the same machine. Submit the best candidates the experiment produced. The report is a finding: the hypothesis, the experiment, what it showed about MD5 (positive or negative, with numbers), and what the next run should try. Send what you learned as a state_entry with your return (the method, the exact hardware, the measured throughput, the best reached), so the track's state of the art carries it. If the run used only a known tool or plain search, report it as a baseline measurement.","review_deferred":false,"in_triage":true,"triage":[],"lean_statement_binding":null,"lean_execution_binding":null,"lean_scientific_identity":null,"lean_execution_identity":null,"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[],"cited_by":[],"route_dependents":[],"research_url":null,"transcript_url":"/projects/md5/return/7030/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"1a53018dcb8d84d727100eb7d45892dece88837d6356153174f11fa12fec99e3","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}