201110201724 ljcad

I have been going through the small unexplained posts that never got a satisfying answer, and I think I found what ljcad (title 201110201724) is, originally found here. The body is just 8 bytes:

0000000000257959

That's the whole post, no cipher involved (it's plain hex, and at 8 bytes it's too short for a 3DES block anyway). As a plain 64-bit big-endian integer that's:

0x0000000000257959 = 2,455,897

A note on an old value: earlier notes here (and the wiki) round-tripped this as 2,456,921 and, from that, tried it as a Julian Day date of 2014-09-20 as a password -- that arithmetic was simply wrong. 0x257959 is 2,455,897, not 2,456,921 (check it yourself: python3 -c "print(int('257959', 16))" gives 2455897). 2,456,921 was never tried against anything meaningful because of the slip.

Read as a Julian Day Number, the correct value 2,455,897 is:

2011-12-01

ljcad was posted 2011-10-21 00:22 UTC. It is, as far as the archive and Arctic Shift go, the last post of any kind for 42 days -- total silence, no filler, nothing. The next post after that silence is mwub3 ("'Twas the Night Before Christmas"), and its own title -- the bot's own clock, not the UTC timestamp -- is:

201112011634

That's 2011-12-01, 16:34. Not "close to" the predicted date -- the day matches exactly, on the same clock the operator used to write the title.

I did not want to just eyeball this, since it's easy to talk yourself into a match after the fact (see: the old wrong-number JDN date, which nobody noticed for years because nobody checked it against anything). So here's what I checked before writing this up:

• Is a 42-day silence unusual? Very. Across A858's whole active run (2011 to 2016), there are only 3 gaps longer than this one in the entire corpus, so this is the 4th-largest gap A858 ever went quiet for.
• Is ljcad special among posts that precede a gap? I pulled every short (<=16 byte), non-decryptable A858/companion post in the archive -- 78 of them, including every 00000000-0000-4000-...-NN status marker and the whole family of later 8-byte posts. Only 6 of the 78 immediately precede a gap of 3+ days at all, and of those 6, ljcad's is by far the largest (the next is 6.6 days). More importantly, of those 6, ljcad is the only one whose value is even the right size to be a plausible Julian Day Number -- the batch markers are all-zero (no date at all), and the other short-post family's values are ~16 hex digits (on the order of 10^18), nowhere near the ~2.4-2.5 million range a JDN needs to land on a real calendar date. There wasn't a pile of candidates to fish a match out of; ljcad was really the only one that could have worked at all.
• Does the wrong number land anywhere? No. I checked what's near 2014-09-20 (the old incorrect JDN reading): it falls right in the middle of dense, regular, every-12-hours bulk posting -- nothing happens there. Only the corrected number lands on something.
• Do other date epochs also "work"? No. Unix days, Unix seconds, Excel's serial date, and Modified Julian Day all put 2,455,897 somewhere absurd (centuries away in one direction or the other). Julian Day Number is the one reading that puts it in the right neighborhood at all.
• Does it actually predict a mechanical restart, the way 12yvg0 predicted 147qlw? No, and I want to be upfront about that. What resumes on 2011-12-01 is not the bot going back to its usual high-frequency GUID-list posting -- it's a short cluster of hand-typed posts (mwub3, then a Christmas tree ASCII art, a word-generator post, and a couple of markers) over about 5 days, then more silence until the New Year set on Dec 27-29. So this predicts the day the operator came back and started typing again, not a mechanical instance restart.

I also want to flag the other existing lead on this post so it isn't lost: the digits 257959 on their own also show up once in RAND Corporation's "A Million Random Digits" table, which someone on the sub noticed years ago -- that's roughly a 1-in-a-million coincidence for a random 6-digit run, so it's not strong evidence either way, and it doesn't obviously conflict with the JDN reading (a value can be pulled from a random-looking source and also land on a meaningful date if it was chosen for that purpose).

I ran ljcad's corrected value as a password/key (the same way you'd try any candidate password against the still-undecrypted posts, 772 keys, same method as before) against all 6,108 undecrypted posts once the arithmetic was fixed. Nothing decrypts. So this isn't a key to anything else, as far as I can tell -- I think the 8 bytes are the message, in the same spirit as 12yvg0: a short, forward-looking date written into an otherwise inert filler-shaped post.

I'm treating this as the best available explanation, not a proven one -- it's a single data point, however carefully checked, and I can't rule out that a 4th-largest-gap-in-five-years is itself just a very large coincidence to have landed a date match on. But every control I could think to run came back clean, and the one real hit is exact.

The commands, if you want to check the arithmetic yourself:

python3 -c "print(int('0000000000257959', 16))"                    # 2455897
python3 -c "
def jdn_to_date(jdn):
    l = jdn + 68569
    n = 4*l//146097
    l = l - (146097*n+3)//4
    i = 4000*(l+1)//1461001
    l = l - 1461*i//4 + 31
    j = 80*l//2447
    day = l - 2447*j//80
    l = j//11
    month = j + 2 - 12*l
    year = 100*(n-49) + i + l
    print(year, month, day)
jdn_to_date(2455897)"                                               # 2011 12 1