A verifier can run every check correctly, log every sub-step green, and still return the wrong verdict — for a mundane reason nobody likes to admit. The party being verified was the one who picked what got measured. Ask a system which cost category to test an estimate against, and you’ll get whichever one makes the estimate look best. Ask a network which servers exist to be counted, and you’ll get the ones that make the count convenient. Every layer of that check can be truthful and reproducible. The whole thing can still be wrong, because the wrong thing was measured.
Toshikatsu Oga and I just published the second paper in a series testing this directly, and this one names the fix rather than just the symptom: the verifier has to derive the coordinate itself, from a source the party being checked doesn’t control — and bind that derived value into the verdict as an output someone else can recompute. Not “trust our number.” A number a third party can rebuild from scratch and get the identical answer.
We show the rule at four separate scales inside one Bitcoin-anchored conduct-record system for agent-facing services: which cost category an estimate gets judged against (derived from the record’s own line items, not asserted); which servers exist to be counted at all (derived from Certificate Transparency logs, not self-declaration); when a verdict was actually created (bracketed by a Bitcoin block-header set nobody can pre-select); and which day and which tool a conduct check samples (derived from a salt committed before the sampling window, combined with a block hash nobody can steer). Four different problems, same underlying shape, same fix.
The part I like best isn’t the fix — it’s that the paper doesn’t stop at “here’s a clean rule.” It goes back and checks where the deployed system actually falls short of its own design, and says so: a time check that runs a full peer-to-peer sync from genesis but only reaches a two-of-three quorum in production; a population coordinate that’s live but has no anchored record yet; a guard that exists as a harness but isn’t wired into the actual decision path; and three real departures from the anchored design, found while writing the paper, one of which the operator’s own verifier would have refused. All three were repaired the same day. That’s the discipline we try to hold everywhere in this work — publish the gap, not just the fix. A verification system’s credibility comes from what it admits, not just what it claims.
Toshikatsu independently built the counterpart state on his own system for this paper, the same way he did for our first one — drove real corrections to the time-axis implementation, and asked the question that turned a refusal into something you could actually query instead of just read about. That’s the second paper we’ve written together, for the same reason the first one mattered: an independent reimplementation either agrees byte-for-byte or it doesn’t, and there’s nowhere to hide either way.
Full paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7425458 (all our published research: api.babyblueviper.com/research). If you’re building verification, timestamping, or transparency-log infrastructure and have run into this exact “who picks the coordinate” problem — I’d like to compare notes.
— Federico, babyblueviper.com