Stage 2 (2026-10-14): the 5^k acceleration, and the verdict

In plain words

We ported mxdys's 5^k-Inc acceleration (RIncs from Sk1like_TC_v2.v) to Python and made it exact for all 16 variants: anything the shared core table does not cover is handed to the real machine.

It is exact and it finds his cycles. - From each line's first F entry it lands on stage 1's final configuration digit for digit, 2.4-4.6 million Incs later, on all 40 lines, with all 327 F entries in between. - On his two proved variants it finds his translated cycles with his exact periods: 669,180 Incs (Sk1like_TC_v1) and 518 Incs after 1.73e10 Incs (Sk1like_TC_v2).

Every line ran to 10^139-10^153 Incs in 40 s, then on to 10^169-10^194 Incs. mxdys's note on line 496 stops at a tape of about 10^64 cells. Nothing settled: - no line halted; - no line entered a translated cycle; - 261-443 escapes (F entries) per line, 13,228 in all.

The tape is a base-5 odometer, and that makes simulation hopeless. - The number of digits is log5(Incs), within 2. - The front holds huge numbers. The only exponents small enough to run down to 0 sit at the far end of the tape (the oldest digits) and in a few recurring "front gadgets" (classes B and G). - Halting needs an exponent of exactly 0 at an escape, so only those places matter. - The far end changes once per factor of 5 in Incs, and a digit dies there far more rarely still. Across the 40 continuations, which cover about 1,100 orders of magnitude of Incs in all, it happened once.

Verdict: (ii), a cryptid family. Whether a line halts depends on the outcome of an endless series of rare events at the tape's end. Each outcome is set by the residues of numbers inherited from the front, which have no pattern we can find.

Per the cryptid protocol: the exact rules are written below, the family is flagged, and the work stops here. There are no kills and no predicted halts. No family-proof route was found: the translated-cycle route is ruled out far beyond any reach that has produced a proof, and the digit language is not a regular invariant even for the proved variants.

What was built (stage 2; Python, stdlib only)

Validation and calibration

Exact reproduction (accel.py validate, all 40 lines). - Start: the configuration at the line's first F entry (stage 1, Inc 127-140). - Run: exactly as many Incs as stage 1 ran, in 1,048-1,844 accelerated macro steps. - Result: the same tape as stage 1's last configuration on all 40 lines, and the same F entries (327 in all). - Line 121 matches only once stage 1's Inc count is corrected (erratum below).

Core table against the machine. On the first 3,000 Incs after each line's first F entry, every Inc the F-free core table covers agrees with the machine: 119,885 of 119,885.

The second F context reduces to the first. One Inc from w^a 00101 00101 w^m r and from w^(a+2) 01 w^m r gives the same tape: - on all 16 variants; - at the front and behind a 00111 digit; - for random tails, m = 1-4 and a = 1-5; - 6,400 of 6,400 cases.

The third context, 0011101 w^m, is literally the tape 00111 01 w^m.

Calibration on mxdys's proved variants (calib.py, 30 s each, from his x0 = (1, 0011^27 00001^8 001)):

So the detector finds both of mxdys's cycles, with his exact periods.

Errata for stage 1. - Inc numbers. Stage 1 skipped Inc boundaries whose tape did not parse into mxdys's digits, so its Inc numbers are low: - by 2 or 11 on 26 lines, all of them before the first F entry, so differences and twin offsets are unaffected; - by 52 on line 121, 50 of them after its first F entry. - mxdys's cycle length. His Inc_Sn 669179 runs 669,180 Incs, so the cycle is 669,180 Incs, not 669,179. Stage 1's own measurement, 1,338,360 Incs = 2 × 669,180, was right.

The rules (cryptid protocol: written out)

1. Configuration (at the start of an Inc, core naming):

0^inf  D>  w^n  d1 w^m1  d2 w^m2  ...  dk w^mk  001 0^inf        (w = 0001, n >= 1)

Here d1..dk are mxdys's 25 digits (digits.MX). Rarely a digit falls outside them, such as class D's 000001 or a rewritten end of tape (below). Such cases are run on the machine itself.

2. Core (shared by all 16 variants; F is never entered). This is mxdys's RInc/Inc table of Sk1like_TC_v1.v and Sk1like_TC_v2.v with the rules that run through F removed (our port: mxinc.py; the F-free cut: accel.core_rinc). The digit cycle is

0011 -> 0011001 -> 001101 -> 00111 -> (carry into the next digit) -> 00101 -> 0011

Each digit's exponent loses 2 per cycle and gains what the next digit hands back. Exponent-0 merges follow his table.

3. Acceleration (all variants). Suppose d1..dk are all cycle digits (00101 0011 0011001 001101 00111) with m_j >= 2·5^(k-j). Then 5^k Incs take

n -> n + 5^(k-1) + 5^k
m_j -> m_j - 2·5^(k-j) + 5^(k-j-1)     (j < k)
m_k -> m_k - 2 + dn

Meanwhile the rest of the tape receives exactly one carry, which must return Tp0 with dn. This is RIncs_spec in Sk1like_TC_v2.v. Its proof only uses passes over the five cycle digits, which never reach state E or F, so it holds for every (E1, F0).

4. Escape: the only rule that depends on the variant. F is entered exactly when the carry meets a 01. Each class has one rule: what one Inc does to w^n 01 w^m r for m >= 1 (m >= 2 in classes I and J). The ten rules are in "The ten escape rules" above. The other two F contexts reduce to this one: - 00101^0 00101^m acts as 01^m with 2 more w in front (checked above); - 0011101^m is 00111^0 01^m.

5. Halting. F reads a 1 only after a glued escape: m = 0, or m = 1 in classes I and J. Which next digits make it halt, at once or one carry later, is listed per class in (b). So a line can halt only if some escape is ever glued.

Results per line (40 s each)

"Smallest m" is the smallest exponent after the 01 at any F entry. The last column is the far end of the tape at the end of the run (the terminal 001^0 last).

What the table shows: - No halts, and no translated cycle. Exact repeats of n and the first 4 digits did occur on lines 64, 124 (1 each), 709, 718 (10 each) and the 6 class-B lines 67, 263, 266, 321, 664, 688 (50 each). Each is a short "front gadget" re-forming after the front resets: for example n=1 | 0011^3 00001^91 0011^1630 001101^0 … on line 67, at Incs 3.9e8, 6.2e9 and 2.1e24. The intervals grow, so this is not a cycle. The digits behind the gadget differ each time. - Escapes are mostly at the front (70%), with m growing with the scale. - The small m values come from two places: - recurring front gadgets in class B: m = 934 (lines 67, 263) and 1632 (266, 321, 664, 688). These come back with the same value again and again; line 67 has m = 1632 at Incs 1e8.6, 1e9.8, 1e24.3, 1e38.5, 1e68.4 and 1e92.0. Class G's smallest value, 47,884 (lines 709, 718), is a single escape deeper in the tape at Inc 1e19; - the tape's far end: m = 6 on lines 44 and 494 at Inc 1e48, an escape 01^6 001 against the terminal.

Where a halt could still come from: the far end of the tape

New digits are made at the front, so the oldest digits sit at the far end. Each far-end digit changes about once each time a carry runs the whole tape, and a whole-tape carry comes once per factor of 5 in Incs. Here is line 285 (class J) traced from Inc 1e6 to 1e188 (endtrace.py, cont.py; the last 4 digits, terminal last):

The pattern holds on every line we traced: - the last digit's exponent barely moves: it stays within 1-3 of a fixed value (0-1 on line 285, 3-4 on line 44 after its death at Inc 1e48, 447,605-447,606 on line 435); - the next digits lose a steady amount per digit added to the tape (about 37 and 187 on line 285), until one dies; - then an older digit, with a much larger exponent, moves up. Line 285: the 1,392 digit runs out at Inc 1e166 and the 111,792 digit moves up. Line 44: the 35 digit runs out at Inc 1e48 and the 50,750 digit moves up.

Each death is a single local event. Its outcome depends on the phases of the dying digit's neighbours at that moment, that is, on residues of numbers inherited from the front long ago.

• Counted. The 40 continuations (from about 1e148 to 1e169-1e194, 1,097 orders of magnitude in all) show 1 death at the far end, on line 285 (enddeaths.py). The line-44 trace from Inc 1e6 shows 1 more, at Inc 1e48. Neither halted.
• How a death makes an escape. On line 44 at Inc 1e47.7 the tape end read 00101^0 001101^6 001. mxdys's rule 00101^0 001101 -> 01 turned it into the escape 01^6 001, where m = 6 is the last digit's exponent. On line 285 the last digit's exponent is 0 or 1, so a glued escape at the end is not ruled out by size.
• Such glued deaths are survivable. We started every variant from w^5 0011^a 00101^0 001101^m 001 with a = 40, 41 and m = 0-3, and ran 10^7 Incs (endglue.py). None of the 128 runs halted; every one rebuilt an ordinary end of tape. So a halt would need something rarer: a death further from the end, or a front gadget drifting to 0.
• Escapes next to the terminal never halt at once. We tested 01^m 001, with and without a 00111^0 in front, m = 0-2, on all 16 variants. Several rewrite the end of the tape: class D makes 000001; class F with m = 0 deletes the terminal, leaving only w^7. The endglue.py runs pass through exactly these escapes (m = 0-3) and recover.

Why simulation cannot settle it. The next digits at the far end lose only tens to hundreds per digit added to the tape, so a death there is separated from the next by tens to hundreds of orders of magnitude of Incs. Our runs saw 0 or 1 per line. A halt needs one specific outcome, out of an unbounded series of such events, whose inputs are residues of numbers with hundreds of digits.

The digit map at the escapes

At each escape the counter hands the escape rule two values: the exponent m and the next digit (digitmap.py). - Next digit. Over all 13,228 escapes, all five phases occur: 0011 2,114, 0011001 1,328, 001101 5,651, 00111 2,789, 00101 1,344, other 2. - No periodic tail. On no line is the second half of the next-digit sequence periodic, nor that of m mod 5. Line 44's first 90 escapes, coded a-e for the phases in the order above:

bbcddaedddccaadaacaacddbbdddeeecdaabaacccccdaacdacbbcdddddacddaacdedabbccbbccbbacecddaacee

• The front escapes are regular; the rest are not.
• The front escapes follow the base-5 times n = 100·25^k − 11 and 400·25^k − 11 of stage 1 (a). For example, one of line 44's front escapes has n = 100·25^42 − 11 (about 5.2e60).
• The exponents they carry, and every escape deeper in the tape, follow no formula stage 1 could find. Here their next digits and residues show no period either.

Is the digit language a regular invariant? No

If one Inc mapped every tape of mxdys's language into the language without halting, the language itself would prove nonhalting. It does not, for any variant. We ran one Inc from 2,000 random tapes of the language per variant (exponents 0-3, closure2.py):

The proved variants fail too, so the reachable tapes are a thin subset of the language. A regular invariant would have to track which phases can meet at the far end, which is the arithmetic above. No upstream decider closes any of the 16 holdout variants, and the critic's hlin run at the proving configuration was 0 of 8 (stage 1 (d)).

Verdict

• (i) Family-proof route: none found. The only proof shape that has closed this core is a translated cycle found by a long accelerated run. It is excluded here to 10^139-10^153 Incs on every line, and to 10^169-10^194 Incs on all 40 in the continuations. That is far beyond the 1.7e10 Incs that Sk1like_TC_v2 needed.
• (ii) Cryptid: yes. The rules are in the section above. The halting question is "does one of infinitely many far-end deaths (or a drifting front gadget) ever give m = 0 with the class's next digit?", and the inputs to each death are residues of inherited huge numbers. Flagged; stopped.
• (iii) Predicted halts: none. No halt to 10^169-10^194 Incs, and no small-m trend that points to one.

Reproduce (stage 2)

From reports/k42/; each step is 2 processes, nice 10, ulimit -v 6e6:

python3 -B accel.py validate 44 64 ...        # exact reproduction of stage 1 (seconds per line)
python3 -B calib.py 30                         # mxdys's two cycles
python3 -B rules2.py 200 7; python3 -B closure2.py 2000 1; python3 -B endglue.py
runs2/run_all.sh 40                            # 40 s per line -> runs2/A<line>.json
runs2/cont_all.sh 30; python3 -B cont.py 285 60; python3 -B cont.py 713 60
python3 -B analyze2.py; python3 -B digitmap.py 44; python3 -B enddeaths.py; python3 -B build_atlas.py