The ten minutes are a rumor

Why some gaps are negative

This isn't bad data. Bitcoin consensus never required timestamps to increase from one block to the next — it only requires a block's timestamp to exceed the median of the previous 11 blocks' timestamps (and stay within two hours of network time going forward). A miner just needs a valid-looking clock reading when they find a hash; nothing stops it from landing a few minutes behind the block it extends, especially when two blocks are found close together by miners whose clocks don't agree.

Of the 15,947 negative gaps: 6,322 are within a minute of zero — essentially clock jitter — 6,578 fall between one and five minutes back, and 3,047 reach further, down to a −1h 59m outlier at height 156,114. All but a handful of those sit in Bitcoin's first two years, when only a few CPU miners existed and clock discipline was looser.

How to treat them

• Don't drop or clip them. They're valid, mined blocks — filtering them out understates real variance and quietly rewrites consensus history.
• Keep them in the histogram, labeled. They're a real, if small, lobe of the distribution — the honest chart shows the dashed line at zero, not a chart that starts there.
• For a "how overdue is this block" metric (like blockface's own since-last-block counter), simple consecutive diff is fine — negatives are rare and self-correct within a block or two.
• For a cleaner per-block pace metric, diff against median-time-past instead of the immediately preceding block — by construction it can't go negative the way a raw consecutive diff can, since MTP only moves forward.

The extremes

Both tails sit almost entirely in Bitcoin's earliest years.