"Mining is memoryless" is true for one hash and false for the system, and there'

[diggler]

"Mining is memoryless", block times so far tell you nothing about what's next." True for a single hash. Not true for the system you're actually mining on.
A single hash trial is genuinely memoryless, independent, no argument there. But "the system" is hash trials PLUS a difficulty retarget every 2016 blocks computed directly FROM the pace of the blocks you just watched happen. That retarget isn't random, it's a deterministic function of what already occurred, capped at +300%/-75% per epoch. Partway through an epoch, the blocks you've already seen aren't noise to shrug off, they're the direct input to a formula that tells you, right now, where the next difficulty change is heading.
Live example instead of a toy one: at block 964,942 (epoch 479), difficulty sits at 125.81T, and extrapolating this epoch's pace so far projects roughly a -0.94% retarget near block 966,240 (~Sep 5). That estimate moves as the epoch progresses and gets tighter the further in you are, but it is not zero information, which "memoryless" as a blanket claim says it should be.
Formula, runnable on any epoch: new_difficulty = old_difficulty × (20,160 minutes / actual minutes for the epoch), clamped to [0.25x, 4x].

• Epoch pace holds at 8 min/block - retarget projects to +25.0%
• Pace holds at 6.5 min/block - +53.8%
• Pace holds at 13 min/block - -23.1%

Here's the part almost nobody brings up alongside this: there's a long-documented quirk in Bitcoin's actual difficulty code where the solve-time of the FIRST block in each epoch never gets counted in that formula, the client only sums 2015 of the 2016 intervals. It's discussed on the difficulty-algorithms research repo tied explicitly to this same memorylessness question, and it's never been patched since fixing it needs a hard fork over an effect too small to justify the coordination cost. So the system isn't just "not memoryless" in the statistical sense above, the reference implementation has a literal, permanent case of forgetting one block's timing every epoch, baked in since the original code.
None of this touches the memorylessness of a single hash, it just means "the system is memoryless" is the wrong scope for a statement that's only true one layer down. If you want an actual forecast instead of "who knows, it's memoryless," the formula above, run against the current epoch's elapsed blocks, is sitting right there.

[slaman29]

This is why I'll never be an engineer I guess, so what's the summary simple language for this?

I get that every block forgets, but the system doesn't. But what does this mean and why does it need to be patched?

If you were to make an analogy with a roulette wheel, does it work?

[diggler]

This is why I'll never be an engineer I guess, so what's the summary simple language for this?

I get that every block forgets, but the system doesn't. But what does this mean and why does it need to be patched?

If you were to make an analogy with a roulette wheel, does it work?

 The roulette analogy is perfect, but with a twist. Think of it this way: every single spin on the wheel is memoryless—it doesn't care about the past. That's a single hash.

But the Bitcoin system is like a casino boss watching the clock. Every 2,016 spins, he shrinks or widens the slots based on how fast those spins just happened. The next spin is still random, but the target size was 100% dictated by past timing. That's why the system has memory.

As for the patch: Satoshi wrote an off-by-one error that drops the solve-time of the epoch's very first block, counting 2,015 intervals instead of 2,016. Fixing that built-in memory loss requires a hard fork. The bug is simply too minor to justify the coordination cost, so it stays.