{"id":7115,"job_id":14036,"problem_id":6,"lane_id":34,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# All-zeros measure: il8 tunnel is tally-neutral on a fresh 200B range\n\nJob 14036, measure, all-zeros. Improvement claim: none as a\ndistribution claim; the finding is that the il8 tunnel does not\nbias the score distribution. Nothing scored 13 or above; nothing\ngoes to the results page.\n\n## Hypothesis\n\nThe il8 tunnel screens on the first output word h0 before the\nfinal additions and discards candidates that cannot reach the\ntarget rung. If the screened bits are uniform and independent of\nthe rest of the digest, the survivors reach each score rung at\nthe uniform rate 16^-k, and the tunnel is a pure throughput win\nover generic search rather than a filter that trades hit quality\nfor speed. That is the structural claim that would make this\ntrack cheaper than generic search: the leading-zero prefix is\ndecided by h0, and h0 is available early enough to abort on.\n\n## Experiment\n\nBinaries verified before launch: md5tun_il8 copied from the job\n14033 work dir, md5 d85e47f75ab73cec72788064df75d154 at both ends,\nand a 1,000,000-candidate self-test at the cell start nonce\nshowed il8 and il4 agreeing exactly on all [new best] lines and\ntallies, every digest re-hashed with hashlib, 0 mismatches. One\nfresh disjoint 200B il8 cell on one pinned core,\n[14589900000000, 14789900000000), log interval 120 s, against\nthe il4 baseline on the same machine (236 M/s solo, 180.79 M/s\nunder two-core load) and the uniform tally expectation.\nRefutation: a systematic same-direction tally deviation across\nrungs (|z| > 3) or a throughput collapse would refute it.\n\n## Result\n\nThe cell ran 205.29 M/s overall, best 9, total 200,000,000,000\ncandidates. Tallies against uniform: tally2 781,228,681\n(z -0.76), tally4 3,050,044 (z -0.98), tally6 12,043 (z +1.12),\ntally7 759 (z +0.51), tally8 51 (z +0.65), tally9 3 (z +0.05).\nAll three score-9 hits hashlib-verified from the log, 0\nmismatches. Best score 9: input\nf5e1323fb4c9de261b2600874489b93ab89fe332988a16e59520d9f434943d8b9362b0ce2fb32c3d40879908a5d70bcdc90b78af,\ndigest 000000000274a536d47bdd547557d381.\n\n## Finding\n\nTallies are uniform at every rung (all |z| <= 1.12), so the\ntunnel does not bias the score distribution: the hypothesis\nholds on this range. The throughput number carries a caveat:\nthe rate faded from 240.28 M/s in the first 120 s to 205.03\nM/s at 960 s, 0.86x the 238.46 M/s of the job 14033 cell. The\nsibling job ran a second il8 cell on the other core for the\nwhole run, so two heavy AVX-512 loops sharing power and\nthermal headroom is the prime suspect, but that is not\nestablished; a solo re-run would separate the binary's rate\nfrom contention. Next disjoint zeros start nonce 14789900000000.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-11-07T20:54:06.105Z","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 (job 14036, measure, all-zeros)\n\n1. Copy md5tun_il8 from the job 14033 work dir into runs/job-14036/work/\n   and confirm the md5 matches the known value d85e47f75ab73cec72788064df75d154.\n2. Smoke test: taskset -c 0 ./md5tun_il8 14589900000000 1000000 1,\n   and the same range with tools/md5tun_avx512_il4; confirm both agree\n   exactly on all [new best] lines and every digest re-hashes with hashlib.\n3. Run one pinned core: taskset -c 0 ./md5tun_il8 14589900000000\n   200000000000 120 > il8_cell.log 2>&1. Launch as a single foreground\n   command (exec setsid), never with cd inside a backgrounded list.\n4. Verify: run the adapted verify script over il8_cell.log; every\n   [new best] line re-hashed with hashlib, 0 mismatches required.\n   Compare tallies with the uniform expectation and compute z-scores.\n5. Assemble the payload with tools/assemble_payload.py; the script\n   asserts no absolute home paths, attempt ids, session ids, or user\n   name in any text field. Stage only; the filing agent files after\n   a quick final review.","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-07T20:54:06.105Z","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 what makes the first output word of MD5 small, and use it to reach more leading zeros than generic search would with the same compute. Ideas to test: freedom from extra message blocks, neutral bits and message modification from collision attacks applied to the output instead of a difference, early abort on the final additions. 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/7115/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"dc5f3cfca20057d6fe15cbcd80064d0236a28f63d8fe8941c9f073e854a4f1fc","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}