{
 "id": "ljcad",
 "title": "201110201724",
 "title_time": "2011-10-20T17:24",
 "author": "[deleted]",
 "account": "A858DE45F56D9BC9",
 "subreddit": "A858DE45F56D9BC9",
 "created_utc": "2011-10-21T00:22:25Z",
 "permalink": "https://www.reddit.com/r/A858DE45F56D9BC9/comments/ljcad/201110201724/",
 "arctic_shift": "https://arctic-shift.photon-reddit.com/api/posts/ids?ids=ljcad",
 "sources": [
  "community-archive",
  "arctic-shift"
 ],
 "body": "00000000 00257959",
 "body_source": "community-archive",
 "body_other_version": null,
 "body_hex_chars": 16,
 "bytes": 8,
 "score": 61,
 "num_comments": 22,
 "category": {
  "code": "U",
  "label": "U unsolved pre-cutover hex"
 },
 "kind": "manual",
 "encryption": "unencrypted",
 "status": "best-guess",
 "summary": "8 bytes, 0x257959 = 2,455,897: the Julian day of 2011-12-01, the day A858 resumed after a 42-day silence. Plain. Open: why it points at that date.",
 "content_type": null,
 "cipher": null,
 "plaintext": null,
 "word_layer": null,
 "credit": {
  "kind": "explanation",
  "what": "0x257959 read as a Julian Day Number: the exact day A858 came back after a 42-day silence. Best guess."
 },
 "decoded_layers": null,
 "guids": null,
 "count_from_length": null,
 "run": null,
 "known_solution": [
  {
   "Method": "plain 8-byte value, no cipher",
   "Result": "0x257959 = 2,455,897 = Julian day of 2011-12-01",
   "Explanation": "Unencrypted 8-byte value 0x257959 = 2,455,897 = Julian day 2011-12-01 (decimal corrected).: the first post after its 42-day silence (mwub3) is dated 2011-12-01, an exact day match; look-elsewhere audit over the 78 short hex posts and epoch controls (Unix, Excel, MJD) support the JDN reading. Why the post points at that date is not confirmed by the operator"
  }
 ],
 "tags": [
  "pre-automation",
  "2011",
  "Unsolved special post",
  "manual",
  "found by this project"
 ],
 "title_zone_hours": -7,
 "title_zone": "UTC−7",
 "writeup": {
  "title": null,
  "markdown": "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](http://www.reddit.com/r/A858DE45F56D9BC9/comments/ljcad/201110201724/). The body is just 8 bytes:\n\n    0000000000257959\n\nThat'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:\n\n    0x0000000000257959 = 2,455,897\n\nA 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.\n\nRead as a **Julian Day Number**, the correct value 2,455,897 is:\n\n    2011-12-01\n\n`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:\n\n    201112011634\n\nThat'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.\n\nI 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:\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n\nI 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).\n\nI 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.\n\nI'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.\n\nThe commands, if you want to check the arithmetic yourself:\n\n    python3 -c \"print(int('0000000000257959', 16))\"                    # 2455897\n    python3 -c \"\n    def jdn_to_date(jdn):\n        l = jdn + 68569\n        n = 4*l//146097\n        l = l - (146097*n+3)//4\n        i = 4000*(l+1)//1461001\n        l = l - 1461*i//4 + 31\n        j = 80*l//2447\n        day = l - 2447*j//80\n        l = j//11\n        month = j + 2 - 12*l\n        year = 100*(n-49) + i + l\n        print(year, month, day)\n    jdn_to_date(2455897)\"                                               # 2011 12 1"
 },
 "page": "posts/ljcad/"
}