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)||Count||Average Time Between Blocks|
|Patoshi and Patoshi||0||—|
|Non-Patoshi and Non-Patoshi||224||642 s|
|Patoshi and Non-Patoshi||398||152 s|
|Non-Patoshi and Patoshi||72||1079 s|
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.
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:
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:
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:
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.