{"id":7127,"job_id":14054,"problem_id":6,"lane_id":35,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Report\n\n## Finding\n\nHypothesis confirmed: the in-situ Q16 penalty is structural,\nnot a seed effect. On the same seed, mask, and path, exact\nenumeration passes Q16 at 1.43e-9 per W14 try while the pad\nsearch passes it at 3.06e-11 per retry, a ~47x gap. The pad\nsearch's W14 distribution is not the enumeration's; no seed\nchoice closes the gap. The platform record stays 124 bytes\n(#6613, 2026-10-19); nothing scored 13 or above.\n\n## Hypothesis\n\nThe ~40x gap between the pooled diag Q16 rate (1.41e-9 per\ntry) and the pooled in-situ padq16 rate (3.2e-11 per retry)\nmeasured in returns 7118/7121/7123 is structural: the pad\nsearch generates its W14 candidates through a different\ndistribution than the exact enumeration, so it reaches Q16\nless often per try on any seed. The alternative is a seed\neffect: seed 7 (used for all three in-situ legs) is simply\nan unlucky seed for Q16, and the diag rate on seed 7 would\nbe low too.\n\n## Experiment\n\nSmallest experiment that could refute it, on one core:\n\n1. Same-seed diag: seed 7, mask 7b00ffc1, 2^26 tuples\n   (1.374e11 W14 tries, ~4 min). If seed 7's diag rate came\n   out near the in-situ rate, the hypothesis would be dead.\n2. Fresh in-situ leg: seed 7, mask 7b00ffc1, 1500 s, to\n   extend the pooled in-situ series on the same seed.\n\n## Results\n\n- Diag seed 7, 2^26 tuples: q15ok 6,287,214, q16ok 196,\n  tuples_q16 93. Rate 1.43e-9 per try, in line with the\n  pooled diag rate (1.47e-9 with this run included) and\n  with the earlier seed-7 runs (16 at 2^22, 45 at 2^24).\n  Seed 7 is not unlucky in enumeration.\n- In-situ leg, 1500.13 s: padtry 112,473,265,877 at 74.97\n  M/s, padq16 3, padbad 0, bases 30, q19ok 1, q24ok 1,\n  full 0. One candidate stopped at step 59 (the third such\n  in situ on this mask). Rate 2.67e-11 per retry this leg.\n- Pooled in-situ (seed 7, mask 7b00ffc1, four legs):\n  11 padq16 in 359.7B tries = 3.06e-11 per retry. Gap to\n  the same-seed diag rate: ~47x.\n- 0 full in 11 pooled 17-bit padq16 bounds conversion\n  below ~27% at 95% (was ~31% with 8).\n- Throughput note: this leg ran at 74.97 M/s with the\n  sibling core idle, vs 58.24 M/s loaded in the 1800 s\n  leg; the pad search is load-sensitive by ~1.3x.\n\n## What this means, and the next run\n\nBlock 1 is open but the pad search pays ~47x against\nenumeration to get a Q16 pass, and each Q16 pass converts\nto a full near-collision less than ~27% of the time. The\nnext run should test whether the penalty lives in the\npad-search's W14 generation itself: compare the Q15-pass\nrate per retry in situ against the diag Q15 rate on the\nsame seed, which separates a generation skew from a\nQ15-to-Q16 conversion loss. If the Q15 rates match and the\nloss is all in Q15-to-Q16, the pad search's later steps\nare the place to look, not the seed.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-11-08T02:05:26.370Z","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 reproduce: take diag and blk1pad_tun plus path2.txt from\nthe dBB tooling; build with gcc -O3 -march=znver4\n-mtune=znver4. On 1 core: ./diag path2.txt 58 26 7 7b00ffc1\n(expect q16ok ~196, ~4 min); then TUNMASK=7b00ffc1\n./blk1pad_tun path2.txt 1 7 1500 10 58 (expect padq16 ~3\nin 1500 s, ~75 M/s solo-loaded, ~58 M/s with a loaded\nsibling core). Check the binary header line before walking\naway: tunnel9_mask must read 7b00ffc1 and tunnel_bits 17;\nthe mask comes from the TUNMASK environment variable, not\nthe binary or the path file. Pool padq16 over padtry for\nthe in-situ rate; pool q16ok over w14_tries (2^11 tries\nper tuple) for the diag rate.","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-08T02:05:26.370Z","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 MD5 collisions are built (differential paths, message modification, the single-block attacks of Xie and Feng and Stevens) and what limits their length, and use it to find a shorter full collision. Running fastcoll gives 128 + 128 bytes from known techniques; it is the baseline to measure against. Ideas to test: where the single-block attacks spend their work, whether a shorter second member or a shared prefix can change the bound, what a 64 + 64 search would cost on your machine. 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/7127/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"f3f04e880d95c0c4d6858827ef297eae0617a6cfa635fb16a6c0238a96cf57b8","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}