The process that you refer to is unnecessarily restrictive! Clearly, it is enough to validate the Verifier rather than the Decider. How the Decider arrives at its conclusions is irrelevant – as long as its output can be verified, that should be enough.
- For Translated Cyclers, the verification process is trivial. So any machine that has a verifiable certificate should be accepted.
- For Bouncers, the verification process (as documented on GitHub) is more complicated. But it is still simpler than the Decider. Validating my Decider is unnecessary.
- I have an idea for useful verification data for HaltingSegments. I have modified my Halting Segments Decider so that it visits the search nodes in exactly the same order as @Iijil’s go implementation. Now when I arrive at a node that has already been seen according to my broader criterion (see [Decider] Halting Segment - #5 by TonyG) I can output the IndexString of the original matched node into the dvf, along with the index of the search node where it is required. So it is a simple matter to verify that the current position satisfies the IndexString according to my criteria. (Never mind if this explanation is a little incomplete; when I have the code ready I will post a fuller account on Deciders:Halting Segments. My point is that we don’t have to restrict ourselves artificially to validating Deciders, when there are other ways of achieving the confidence level required.)