A New Mystery in Patoshi Timestamps

Patoshi is the name I gave to the prominent miner that in 2009-2010 mined

about 1.1M bitcoins, and that some people associate with Satoshi Nakamoto. Last time I wrote about Patoshi was in April, 2019. At that time, I posted in order to clarify what we know, technically, about how Patoshi mined. Impossible was for me to foresee that one of the early coinbase being spent recently would cause such an impact in the crazy and uninformed market and the Patoshi pattern would be on the news. Nor I could foresee that a anonymous person would be signing 145 of the early coinbase keys to show a US court how Faketoshi committed fraud, and again everyone would go to check if those coinbases belonged to the Patoshi set. These events triggered an impressive number of tweets, posts and videos about Satoshi. A new wave of Satoshi hunters appeared. But how many people actually pay attention to the technical details? How many computer scientists read my blog? How many paparazzi?

Back in April I posted the following table showing the events where the timestamps of two consecutive blocks were reversed, and by how much time, in average, during the first years of Bitcoin mining:

Case (parent and child)CountAverage Time Between Blocks
Patoshi and Patoshi0
Non-Patoshi and Non-Patoshi224642 s
Patoshi and Non-Patoshi398152 s
Non-Patoshi and Patoshi721079 s
Total694
Inversion of timestamps in consecutive blocks

You can see that the average timestamps deltas (when timestamps are inverted) largely differ between Patoshi and non-Patoshi blocks. I realized in 2019 this was far from normal, but I waited for somebody else to notice the oddity. In 2014, I published about the strange timestamp gaps. Well, it seems that few people reads my post until the end 🙂 Only one person (that preferred to remain anonymous) also detected the anomaly in Patoshi’s timestamps. Now enough time has passed, and still I don’t have a good explanation for the strange way Patoshi timestamped his blocks. Therefore in this post I will expand that research so that more people can think on this. I’ll also summarize possible (some maybe surprising) explanations. This is yet another mystery about Patoshi blocks, and I only pretend to leave you with more questions than answers.

Let’s begin with an histogram of how timestamps differences (or “deltas”) are distributed between consecutive blocks in the first 50K blocks, when none of the blocks belong to the Patoshi pattern. In the X-axis we show buckets of 10 seconds each, so the labels on the X-axis show time in seconds divided by 10. In the Y-axis, we show the number of events counted for that slot.

Timestamp deltas between Non-Patoshi blocks in the first 50K blocks

Curved traced by the bar graph looks like an exponential distribution, as it should. There curve may not be a perfect exponential, as distributed timestamps are not fetched from an unique global clock, and also timestamps in nodes are not updated in a continued basis during mining, but only every few seconds. Nevertheless the graph looks as one would expect, and the average timestamp delta is 654 seconds.

Now let’s look what happens between Patoshi blocks:

It seems that most block timestamps generally start 312 (about 5 minutes) s seconds after the previous timestamp. Also it appears as if Patoshi refused to mine many blocks after 25 minutes (1500 seconds). This strange pattern is a new way to distinguish the Patoshi pattern from all other coinbase sets. We had three methods already (steep fast extranonce increment, reduced nonce LSB range, no timestamp reversals), and now we add a fourth (and in a next post I will show a fifth!). So why timestamp deltas are oddly distributed is a new unsolved mystery for our large collection. In my opinion, the existence of so many distinguishers is an indicator that Patoshi wanted his/her blocks to be identified.

If you look carefully at the timestamp delta distribution, there are a high number of timestamp deltas before 312 seconds that make for me even more difficult to explain the steep cliff shape. Luckily this one puzzle we can unravel with some information we already know. The reason of this “noise” is a segment in the Patoshi pattern that I named “Double Helix”, because it looks graphically as DNA. Here is a graph of this segment:

The double-helix interval in Patoshi pattern (blocks 1400-1916)

You can explore this pattern in SatoshiBlocks website. The double-helix pattern was probably caused by two instances of the Patoshi software/hardware running in parallel. We don’t know if this was a mistake made by Patoshi or it was intended for testing an improved mining setup. But the timestamps between blocks of the two Patoshi lines of the double-helix do not show the same delta distribution, as if internally, maybe due to physical proximity, there was no delay between blocks. Here is the histogram without considering the blocks in the double-helix:

Timestamps deltas between Patoshi blocks, excluding blocks 1400..1916

Now it looks much cleaner! The remaining complementary graphs, being timestamps deltas between Patoshi blocks and non-Patoshi blocks and vice-versa, look quite normal, so I’ll omit them.

One may think that Patoshi may have decided to discard blocks when they were mined too close, not to overload the early and frail network, since very few transactions were included in early blocks. However, if we look at the distribution of extranonces between consecutive Patoshi blocks, we can see the curve is still exponential, meaning that no blocks were discarded:

The extranonce deltas between consecutive Patoshi blocks

Still it’s possible that Patoshi just turned off his mining equipment for about 5 minutes after mining a block. Is that plausible? How can we explain the differences in timestamp deltas? We provide several hypothesis to the reader:

  • Patoshi turned off his mining equipment for about 5 minutes after mining a block. Maybe this was required in order to broadcast the block. Or maybe he was doing it to let other miners mine following blocks. The fact that Patoshi reduced his hashrate in several steps during the first year indicates that he may well be able to do it also at the block granularity. It’s even possible that the increased his hashrate if a block was delayed longer than 12 minutes, which could explain the strange timestamp delta distribution.
  • Patoshi software avoided two blocks having the same timestamp. Therefore if a block was mined locally and immediately the mining of a following block began, then the following block timestamp would be artificially incremented a random number not less than 300 seconds.

The artificial addition time to the timestamp seems to be a better overall explanation, because it could also explain why after 25 minutes it seems that Patoshi reduces the number of mined blocks. The correct interpretation of the graph would be that the previous intervals are artificially incremented, and the tail in the exponential probability after 25 minutes is correctly represented.

Because we’re living difficult times, and since science without joy is too boring, I give you some far-fetched and fun explanations of the timestamp delta phenomenon:

  • Patoshi was mining from outer space, somewhere in our solar system. It took approximately 150 seconds for the radio signals to travel to his spaceship. To compensate for the delay, and avoid being detected, he/she/it used a real-time clock being 300 seconds ahead of time in earth. His timestamps were faked but that was not noticed on earth. That worked well when mining on top of a block he didn’t create. However, Patoshi didn’t realize that the round-trip time of transmission of his own blocks to and from earth would generate a gap in the timestamps, if not specifically compensated. That’s why we see the gap only between his own blocks.
  • Although timestamp LSB (nor the byte with mask 0xff00) in Patoshi blocks have uniform distributions, somehow grinding the timestamp was used to obtain blocks that were more favorable to find solutions for.

That all for today. I encourage you not to trust any of my graphs, and to do the computations yourself. Do not trust any third partes 🙂 There is always some (low) probability that my software is buggy.

If you find additional (possibly better) explanations, leave me a message here or better ping me in twitter at @SDLerner.

, , , , ,

  1. #1 by btcfacile on June 22, 2020 - 11:46 pm

    Hi,

    Do you think there is a possiblility Patoshi pre-mined some blocks?

    Patoshi testing routines are weirds or he/she just messed a little with the Timestamps,

    a little like with the genesis block.

    • #2 by SDLerner on June 23, 2020 - 3:08 am

      No, I don’t think there was a pre-mine, because there many public events witnessed by many people associated with Bitcoin during the early years.

  2. #3 by Frank Oppedijk on June 24, 2020 - 8:20 am

    I have a comment about “if we look at the distribution of extranonces between consecutive Patoshi blocks, we can see the curve is still exponential, meaning that no blocks were discarded”. My opinion is that if Patishi did throw away all blocks that were mined within 5 minutes of the previous block, the extraNonce values that would be discarded would be proportional across the board. So you wouldn’t notice that in the exponential graph. Or am I missing something?

  3. #4 by TechMiX on June 24, 2020 - 2:47 pm

    Nice catch 🙂

    About the minimum time delta of 300 seconds, I think it doesn’t apply to the first two blocks of a mining season. Look at time delta of these blocks:
    – 1 and 2 -> 79s
    – 15 and 16 -> 12s
    – 26 and 27 -> 123s
    – 38 and 39 -> 23s

    • #5 by SDLerner on June 25, 2020 - 2:47 am

      Yes, the first 40 blocks do not show this pattern. The next 500 blocks show a delay of 180 seconds approximately. The rest show a delay of 300 seconds.

    • #6 by SDLerner on August 27, 2020 - 11:50 pm

      This may be because the 5 threads that mine synchronize to sleep after the first block has been created, not before it.

  4. #7 by Jeremy Davis on June 24, 2020 - 7:55 pm

    This would make sense while trying to bootstrap a distributed system and wanting to be fair about it. I would try to balance wanting ~10 minute blocks, not hoarding if I got lucky, and the network not having a consistent hash-power (both high and low).
    Just a guess, but as a programmer, the easiest thing would be to way over-provision my personal mining pool, and then sprinkle with Sleep() with various random thresholds.
    Maybe look at the estimated hashrate over the same period? Satoshi probably _was_ the network early on, with hobbyists coming and going. As a consistent amount of hash started to build, I would probably start to phase out.

Leave a comment