<p>I'm not the author, but found this code:</p>

<ul>
<li><a href="http://blockchainsql.io/wkeno3" rel="nofollow noreferrer">http://blockchainsql.io/wkeno3</a></li>
</ul>

<p>Top 10 longest (using timestamp in block header, which can vary up to 2 hours from actual time)</p>

<ol>
<li>Block 1: 2009-01-03 463160 seconds (5 days, ~8 hours)</li>
<li>Block 15324: 2009-05-22 90532 seconds (~25 hours)</li>
<li>Block 16564: 2009-06-05 90390 seconds (~25 hours)</li>
<li>Block 15: 2009-01-09 87157 seconds (~24 hours)</li>
<li>Block 16592: 2009-06-06 73782 seconds (~20 hours)</li>
</ol>

CC BY-SA 4.0
2019-06-21T20:18:55.743Z
2019-06-21T20:33:55.747Z
2019-06-21T20:33:55.747Z
Stephen Gornick
<p>the shortest is 0 seconds</p>

<p>the longest is 6 days (between #0 and #1)</p>

CC BY-SA 4.0
2018-07-31T19:40:00.963Z
the timestamp in block #N can be even less than in block #(N-1), because the time on computers in the world is not accurate.
amaclin
CC BY-SA 4.0
2018-07-31T19:51:55.533Z
By this reasoning surely the shortest block is minus one hour or so.
Pieter Wuille
CC BY-SA 4.0
2018-07-31T21:25:14.977Z
@Pieter, the `length` of interval can not be negative :)
amaclin
CC BY-SA 4.0
2018-07-31T21:30:31.550Z
@amaclin I'm aware. My comment was a way of pointing out that using the timestamps of blocks to determine the length of intervals is meaningless.
Pieter Wuille
CC BY-SA 4.0
2018-08-01T04:46:40.797Z
@Pieter, you know that I know it :) I am only answering stupid question by OP. Of course, the stupid question can not have meaningful reply. Let us give people the chance to study themselves.
amaclin
CC BY-SA 4.0
2018-08-01T08:25:50.660Z
@Cluster2k two blocks being found at the same time does not necessarily mean a hash collision. It is more likely the two blocks would have distinct hashes, but the same blockheight, found at pretty much the exact same moment.
chytrik
CC BY-SA 4.0
2018-07-31T15:23:34.160Z
2018-07-31T15:23:34.160Z
amaclin
<p>I also used the blockchain data query that <a href="https://bitcoin.stackexchange.com/a/88539/5406">@Stephen Gornick mentioned</a>: <a href="http://blockchainsql.io/wkeno3" rel="nofollow noreferrer">http://blockchainsql.io/wkeno3</a>, but excluded all the blocks found before the difficulty increased for the first time at height 32,256 on   2009-12-30. Before that point in time, the network’s hashrate was less than the minimum difficulty, so comparing those block intervals doesn’t seem like a fair comparison. I’m assuming that the timestamps on blocks are accurate, and haven’t verified for all of these whether e.g. the timestamp was shifted due to time-rolling.</p>
<p>After the first difficulty increase, the top 10 longest block intervals were:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th style="text-align: right;">Block</th>
<th style="text-align: center;">Date</th>
<th style="text-align: right;">Interval [h:m:s]</th>
<th style="text-align: right;">Interval [s]</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: right;">74638</td>
<td style="text-align: center;">2010-08-15 23:53:59</td>
<td style="text-align: right;">06:51:16</td>
<td style="text-align: right;">24676</td>
</tr>
<tr>
<td style="text-align: right;">32647</td>
<td style="text-align: center;">2010-01-02 09:05:15</td>
<td style="text-align: right;">03:28:54</td>
<td style="text-align: right;">12534</td>
</tr>
<tr>
<td style="text-align: right;">32629</td>
<td style="text-align: center;">2010-01-02 04:37:10</td>
<td style="text-align: right;">03:06:15</td>
<td style="text-align: right;">11175</td>
</tr>
<tr>
<td style="text-align: right;">155290</td>
<td style="text-align: center;">2011-11-30 01:16:45</td>
<td style="text-align: right;">02:24:50</td>
<td style="text-align: right;">8690</td>
</tr>
<tr>
<td style="text-align: right;">149098</td>
<td style="text-align: center;">2011-10-13 08:40:50</td>
<td style="text-align: right;">02:21:01</td>
<td style="text-align: right;">8461</td>
</tr>
<tr>
<td style="text-align: right;">689301</td>
<td style="text-align: center;">2021-07-01 12:46:53</td>
<td style="text-align: right;">02:19:14</td>
<td style="text-align: right;">8354</td>
</tr>
<tr>
<td style="text-align: right;">70718</td>
<td style="text-align: center;">2010-07-28 02:32:27</td>
<td style="text-align: right;">02:15:53</td>
<td style="text-align: right;">8153</td>
</tr>
<tr>
<td style="text-align: right;">70665</td>
<td style="text-align: center;">2010-07-27 18:31:52</td>
<td style="text-align: right;">02:13:14</td>
<td style="text-align: right;">7994</td>
</tr>
<tr>
<td style="text-align: right;">270194</td>
<td style="text-align: center;">2013-11-17 23:36:46</td>
<td style="text-align: right;">02:09:01</td>
<td style="text-align: right;">7741</td>
</tr>
<tr>
<td style="text-align: right;">301596</td>
<td style="text-align: center;">2014-05-19 21:08:58</td>
<td style="text-align: right;">02:02:15</td>
<td style="text-align: right;">7335</td>
</tr>
</tbody>
</table>
</div>
<p>Given that timestamps can be off and have been off, and this would affect short block times much more significantly, I did not look for the shortest block interval, since it would require sifting through a lot of false positives.</p>

CC BY-SA 4.0
2023-12-07T13:05:30.593Z
2023-12-07T13:45:48.250Z
2023-12-07T13:45:48.250Z
Murch
<p>The shortest time between 2 blocks is impossible to give since the timestamp of a block is not that strict, since its not important to record the timestamp more accurately than to the second.  </p>

<p>The reason for negative times between some blocks is not due to timestamps of blocks being "non strict" or whatever silly stuff above posters said.  I can't give you the correct answer because its just been too long since I researched mining in great depth. It has to do with the way blockchains are verified and large pools having different chains at times (forks).  Within 6 confirmations the longest chain will have been verified and overwrite any blocks recorded from a shorter chain.</p>

<p>None the less, the shortest time between 2 blocks is &lt; 1s > 0s some odd number of milliseconds.</p>

CC BY-SA 4.0
2020-02-17T18:17:44.203Z
2020-02-19T10:35:44.203Z
2020-02-19T10:35:44.203Z
Skimanner
<p>(This data is current through block 535276.)</p>

<p>Based on <strong>block timestamps</strong> (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1.  The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and <a href="https://www.blockchain.com/btc/block/00000000720e7a19e31ca6cc9d2364705b49590f0ede8b0356cb46a8e486ab8f" rel="noreferrer">15324</a>.</p>

<p>For "shortest", since timestamps are not strictly enforced and can be fudged accidentally or intentionally, it is possible for a block to have an earlier timestamp than its predecessor, by up to 2 hours (7200 seconds), in which case the time difference is negative.  This has happened 13828 times.  The most negative difference is &minus;7125 seconds (1 hour 58 minutes 45 seconds) between blocks 156113 and <a href="https://www.blockchain.com/btc/block/000000000000008384e9d6e4e0c6266e824d90ed3e7f7b59149799cc697613fd" rel="noreferrer">156114</a>.</p>

<p>There have been 222 blocks with the same timestamp as their predecessor, giving a difference of 0.</p>

<p>The script I used to gather this data is at <a href="https://github.com/neldredge/bitcoin-blocks" rel="noreferrer">https://github.com/neldredge/bitcoin-blocks</a>.</p>

<p>Actual block intervals are hard to know precisely, since we have no way of knowing for sure the actual time at which each block was mined.  Some sites like blockchain.info record the first time at which their node received the block, but there is an unknown propagation delay between the time a block is actually mined and the time at which some other node receives it (though for a well connected node it is probably not much more than 1 second).  It is also possible to receive blocks out of order, so the difference in receive times could also be negative.  Moreover, such data is obviously not available for early blocks before the existence of the site in question.</p>

<p>In principle it could be possible to look for the longest and shortest difference between receive times, but I don't know how to retrieve that data in bulk.</p>

CC BY-SA 4.0
2019-02-12T16:06:40.950Z
3rd longest would also be interesting:)
tobi
CC BY-SA 4.0
2018-08-05T23:21:51.170Z
2018-12-22T01:02:46.223Z
2018-12-22T01:02:46.223Z
Nate Eldredge
<p>Bitcoin block interval time is on average 10 minutes, that is the difficulty is adjusted in such a way that every 10 minutes a miner will manage to find the right hash. This is just an average time though, the actual distribution for time confirmation is Poissonian.</p>

<p>What is the shortest and longest block interval ever recorded in Bitcoin?</p>

<block><confirmations><block-interval><confirmation-time-estimation>
Shortest and Longest block interval time ever recorded in Bitcoin
Rexcirus
# Shortest and Longest block interval time ever recorded in Bitcoin

(Asked by: username_0 on 2018-07-31)

Bitcoin block interval time is on average 10 minutes, that is the difficulty is adjusted in such a way that every 10 minutes a miner will manage to find the right hash. This is just an average time though, the actual distribution for time confirmation is Poissonian.

What is the shortest and longest block interval ever recorded in Bitcoin?

**Tags:** block, confirmations, block-interval, confirmation-time-estimation


---

## 5 answers

### Answer by username_7 on 2018-08-05. Score: 14 | Accepted answer

(This data is current through block 535276.)

Based on **block timestamps** (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1. The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and [15324](https://www.blockchain.com/btc/block/00000000720e7a19e31ca6cc9d2364705b49590f0ede8b0356cb46a8e486ab8f).

For "shortest", since timestamps are not strictly enforced and can be fudged accidentally or intentionally, it is possible for a block to have an earlier timestamp than its predecessor, by up to 2 hours (7200 seconds), in which case the time difference is negative. This has happened 13828 times. The most negative difference is −7125 seconds (1 hour 58 minutes 45 seconds) between blocks 156113 and [156114](https://www.blockchain.com/btc/block/000000000000008384e9d6e4e0c6266e824d90ed3e7f7b59149799cc697613fd).

There have been 222 blocks with the same timestamp as their predecessor, giving a difference of 0.

The script I used to gather this data is at <https://github.com/neldredge/bitcoin-blocks>.

Actual block intervals are hard to know precisely, since we have no way of knowing for sure the actual time at which each block was mined. Some sites like blockchain.info record the first time at which their node received the block, but there is an unknown propagation delay between the time a block is actually mined and the time at which some other node receives it (though for a well connected node it is probably not much more than 1 second). It is also possible to receive blocks out of order, so the difference in receive times could also be negative. Moreover, such data is obviously not available for early blocks before the existence of the site in question.

In principle it could be possible to look for the longest and shortest difference between receive times, but I don't know how to retrieve that data in bulk.

> **Comments:**
> **username_8**: 3rd longest would also be interesting:)  

---

### Answer by username_1 on 2019-06-21. Score: 4

I'm not the author, but found this code:

* <http://blockchainsql.io/wkeno3>

Top 10 longest (using timestamp in block header, which can vary up to 2 hours from actual time)

1. Block 1: 2009-01-03 463160 seconds (5 days, ~8 hours)
2. Block 15324: 2009-05-22 90532 seconds (~25 hours)
3. Block 16564: 2009-06-05 90390 seconds (~25 hours)
4. Block 15: 2009-01-09 87157 seconds (~24 hours)
5. Block 16592: 2009-06-06 73782 seconds (~20 hours)


---

### Answer by username_2 on 2018-07-31. Score: 2

the shortest is 0 seconds

the longest is 6 days (between #0 and #1)

> **Comments:**
> **username_2**: the timestamp in block #N can be even less than in block #(N-1), because the time on computers in the world is not accurate.  
> **username_3**: By this reasoning surely the shortest block is minus one hour or so.  
> **username_2**: @username_3, the `length` of interval can not be negative :)  
> **username_3**: @username_2 I'm aware. My comment was a way of pointing out that using the timestamps of blocks to determine the length of intervals is meaningless.  
> **username_2**: @username_3, you know that I know it :) I am only answering stupid question by OP. Of course, the stupid question can not have meaningful reply. Let us give people the chance to study themselves.  
> **username_4**: @Cluster2k two blocks being found at the same time does not necessarily mean a hash collision. It is more likely the two blocks would have distinct hashes, but the same blockheight, found at pretty much the exact same moment.  

---

### Answer by username_5 on 2023-12-07. Score: 2

I also used the blockchain data query that [@username_1 mentioned](https://bitcoin.stackexchange.com/a/88539/5406): <http://blockchainsql.io/wkeno3>, but excluded all the blocks found before the difficulty increased for the first time at height 32,256 on 2009-12-30. Before that point in time, the network’s hashrate was less than the minimum difficulty, so comparing those block intervals doesn’t seem like a fair comparison. I’m assuming that the timestamps on blocks are accurate, and haven’t verified for all of these whether e.g. the timestamp was shifted due to time-rolling.

After the first difficulty increase, the top 10 longest block intervals were:

| Block | Date | Interval [h:m:s] | Interval [s] |
| --- | --- | --- | --- |
| 74638 | 2010-08-15 23:53:59 | 06:51:16 | 24676 |
| 32647 | 2010-01-02 09:05:15 | 03:28:54 | 12534 |
| 32629 | 2010-01-02 04:37:10 | 03:06:15 | 11175 |
| 155290 | 2011-11-30 01:16:45 | 02:24:50 | 8690 |
| 149098 | 2011-10-13 08:40:50 | 02:21:01 | 8461 |
| 689301 | 2021-07-01 12:46:53 | 02:19:14 | 8354 |
| 70718 | 2010-07-28 02:32:27 | 02:15:53 | 8153 |
| 70665 | 2010-07-27 18:31:52 | 02:13:14 | 7994 |
| 270194 | 2013-11-17 23:36:46 | 02:09:01 | 7741 |
| 301596 | 2014-05-19 21:08:58 | 02:02:15 | 7335 |

Given that timestamps can be off and have been off, and this would affect short block times much more significantly, I did not look for the shortest block interval, since it would require sifting through a lot of false positives.


---

### Answer by username_6 on 2020-02-17. Score: 1

The shortest time between 2 blocks is impossible to give since the timestamp of a block is not that strict, since its not important to record the timestamp more accurately than to the second.

The reason for negative times between some blocks is not due to timestamps of blocks being "non strict" or whatever silly stuff above posters said. I can't give you the correct answer because its just been too long since I researched mining in great depth. It has to do with the way blockchains are verified and large pools having different chains at times (forks). Within 6 confirmations the longest chain will have been verified and overwrite any blocks recorded from a shorter chain.

None the less, the shortest time between 2 blocks is < 1s > 0s some odd number of milliseconds.


---

