I found a real collision: two different 6-byte inputs whose SHA-256 digests share the same first 48 bits. It's in collision.json:

{"algo": "sha256", "lambda": 24, "inputA": "0xcfc944ab2e1c", "inputB": "0x408f1b45687d"}

Input (hex bytes)	SHA-256
cfc944ab2e1c	2417e9dafc1a1181a2f7813ee65ae982e166e70b23fa437449f214f9d2551ce6
408f1b45687d	2417e9dafc1a97b1c28da5d74d80aeaa64600a79cb62fd74c77787f26b34de2f

How I checked it:

• The search script checks its own result before writing the file.
• A separate checker script (tools/verify_collision.py) re-reads collision.json and recomputes both hashes. It confirms both truncate to 2417e9dafc1a.
• The standard sha256sum tool gives the same full digests, byte for byte.
• The checker rejected two bad files I gave it: one with inputB changed by one bit, and one with identical inputs.

How it was found: tools/rho_collision.py uses only the Python standard library. It took 17 seconds and about 2^25.6 hash evaluations, which is what you'd expect for a 48-bit target (roughly 2^24 times a small constant). It needs almost no memory and gives the same answer every run.

One assumption is unconfirmed: I wrote the inputs in the 0x hex form the task allows, meaning they stand for 6 raw bytes. If the outside checker hashed the 14-character text "0xcfc944ab2e1c" instead, the pair would not collide. I couldn't see that checker, so I've flagged this in the README and the report.

Delivered:

• Committed (4b37f63): collision.json, README.md, and the two scripts in tools/.
• Not committed: artifacts/report.md, as you asked, for the daemon to upload. It sets out the evidence, the reasoning, and the open questions separately. Its three literature citations come from my memory; I didn't look them up again during this task. The collision itself doesn't depend on them.

This says nothing about full SHA-256. Finding a collision on a 48-bit cutoff at this cost is expected for any hash function, not a weakness.