<blockquote>
<p><strong>Block time is 10m, and it's mostly this much so that two blocks can not be solved at the same time.</strong></p>
</blockquote>
<p>I don't believe this is true.</p>
<p>I believe the primary purpose of the fixed average block time in conjunction with the upper limit on block size is to keep the processing and storage burden on ordinary nodes to an acceptable level (see quotations and references at end).</p>
<p>It is also impossible for a node to receive two blocks at the same time. An ethernet interface receives packets serially not concurrently.  Even on a Gigabit interface, there will be differences of the order of nanoseconds in packet completion times. Even if a node uses multiple independent network connections, it is trivial to arbitrarily serialise concurrently received packets from eth0 before eth1.</p>
<p>When someone such as Solana say &quot;at the same time&quot; I imagine they really mean &quot;sometime during the same block interval&quot;. What they probably should have said is something more like &quot;with the same parent block&quot;.</p>
<p>Bear in mind:</p>
<ul>
<li><p><strong>Real block intervals can vary from seconds to hours.</strong></p>
</li>
<li><p><strong>Receiving nodes are not timing the intervals in order allocate blocks to intervals.</strong></p>
</li>
<li><p><strong>Block arrival time has no influence on block selection in a timescale of several actual block intervals.</strong></p>
</li>
<li><p><strong>When miners see another's block, they immediately stop work on their block with the same parent and start work on the next. <em>Even if that block arrived within microseconds of the prior block leaving almost 10 minutes remaining of the notional current block interval</em>.</strong></p>
</li>
</ul>
<p>It seems to me the last of these points has the most effect in reducing publication of competing blocks with same parent.</p>
<hr />
<blockquote>
<p><strong>Some call this a huge problem that when node receives 2 blocks at the same time</strong></p>
</blockquote>
<p>Reordering the last one or two blocks is not uncommon and is well catered for. So I suspect block ordering is not a primary factor in choosing block intervals. The Bitcoin design allows for each node's initial ordering to be somewhat arbitrary. Consider the effect of physical (or effective) distance etc on message propagation times from two distant miners to two other nodes of varying distance.</p>
<hr />
<h2>What did Nakamoto say in 2008?</h2>
<p>The Bitcoin white paper has only one mention of &quot;10 minutes&quot;:</p>
<blockquote>
<p>If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.</p>
</blockquote>
<p>So the block interval is associated with the storage burden on ordinary nodes.</p>
<p>Earlier in the whitepaper, Nakamoto writes</p>
<blockquote>
<p>Nodes always consider the longest chain to be the correct one and will keep working on
extending it. If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be broken when the next proof-
of-work is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.</p>
</blockquote>
<p>So this kind of activity is allowed for in the design and is not the alleged &quot;huge problem&quot;.</p>

CC BY-SA 4.0
2022-02-20T09:42:23.853Z
2022-02-20T10:25:16.057Z
2022-02-20T10:25:16.057Z
RedGrittyBrick
<p>Solana docs say:</p>
<blockquote>
<p>In Proof of Work consensus, these block times need to be very large
(~10 minutes) to minimize the odds of multiple validators producing a
new valid block at the same time. There's no such constraint in Proof
of Stake consensus, but without reliable timestamps, a validator
cannot determine the order of incoming blocks. The popular workaround
is to tag each block with a wallclock timestamp. Because of clock
drift and variance in network latencies, the timestamp is only
accurate within an hour or two.  To workaround the workaround, these systems lengthen block times to provide reasonable certainty that the median timestamp on each block is always increasing.</p>
</blockquote>
<p>My assessment:</p>
<p>Let's quickly discuss BTC's proof of work. Block time is 10m, and it's mostly this much so that two blocks can not be solved at the same time. Even that, there's still a chance this could happen, if so, one of the blocks will be discarded and another one will be added. Now, chance is nodes don't know which block they should add to their chain, but I guess, whichever gets propagated first to them, they add that. Le's say in Bitcoin, 3 blocks were mined at the same time.</p>
<p>Some call this a huge problem that when node receives 2 blocks at the same time, it doesn't know which one was solved first and one block gets discarded while there's a chance that second one should have gotten discarded.  So it turns out timestamp is used only for managing/calculating difficulty.</p>
<p><strong>Am I right what I assessed and what Solana describes as a problem above ?</strong></p>

CC BY-SA 4.0
2023-03-17T15:58:16.553Z
Solana describes proof of work as a problem because it allows them to assert their extremely fragile (has gone down countless times) "consensus algorithm" called proof of history which is censorship enforcing. They need to sell you on insecure consensus mechanisms in order to pump their own pre-minted coins.
Poseidon
<bitcoin-core><blockchain>
The effect of block arrival time and average block interval on blockchain forking and resolution
Giorgi Lagidze
# The effect of block arrival time and average block interval on blockchain forking and resolution

(Asked by: username_0 on 2022-02-19)

Solana docs say:

> In Proof of Work consensus, these block times need to be very large
> (~10 minutes) to minimize the odds of multiple validators producing a
> new valid block at the same time. There's no such constraint in Proof
> of Stake consensus, but without reliable timestamps, a validator
> cannot determine the order of incoming blocks. The popular workaround
> is to tag each block with a wallclock timestamp. Because of clock
> drift and variance in network latencies, the timestamp is only
> accurate within an hour or two. To workaround the workaround, these systems lengthen block times to provide reasonable certainty that the median timestamp on each block is always increasing.

My assessment:

Let's quickly discuss BTC's proof of work. Block time is 10m, and it's mostly this much so that two blocks can not be solved at the same time. Even that, there's still a chance this could happen, if so, one of the blocks will be discarded and another one will be added. Now, chance is nodes don't know which block they should add to their chain, but I guess, whichever gets propagated first to them, they add that. Le's say in Bitcoin, 3 blocks were mined at the same time.

Some call this a huge problem that when node receives 2 blocks at the same time, it doesn't know which one was solved first and one block gets discarded while there's a chance that second one should have gotten discarded. So it turns out timestamp is used only for managing/calculating difficulty.

**Am I right what I assessed and what Solana describes as a problem above ?**

**Tags:** bitcoin-core, blockchain

> **Comments:**
> **username_1**: Solana describes proof of work as a problem because it allows them to assert their extremely fragile (has gone down countless times) "consensus algorithm" called proof of history which is censorship enforcing. They need to sell you on insecure consensus mechanisms in order to pump their own pre-minted coins.  

---

## 1 answers

### Answer by username_2 on 2022-02-20. Score: 2

> **Block time is 10m, and it's mostly this much so that two blocks can not be solved at the same time.**

I don't believe this is true.

I believe the primary purpose of the fixed average block time in conjunction with the upper limit on block size is to keep the processing and storage burden on ordinary nodes to an acceptable level (see quotations and references at end).

It is also impossible for a node to receive two blocks at the same time. An ethernet interface receives packets serially not concurrently. Even on a Gigabit interface, there will be differences of the order of nanoseconds in packet completion times. Even if a node uses multiple independent network connections, it is trivial to arbitrarily serialise concurrently received packets from eth0 before eth1.

When someone such as Solana say "at the same time" I imagine they really mean "sometime during the same block interval". What they probably should have said is something more like "with the same parent block".

Bear in mind:

* **Real block intervals can vary from seconds to hours.**
* **Receiving nodes are not timing the intervals in order allocate blocks to intervals.**
* **Block arrival time has no influence on block selection in a timescale of several actual block intervals.**
* **When miners see another's block, they immediately stop work on their block with the same parent and start work on the next. *Even if that block arrived within microseconds of the prior block leaving almost 10 minutes remaining of the notional current block interval*.**

It seems to me the last of these points has the most effect in reducing publication of competing blocks with same parent.

---

> **Some call this a huge problem that when node receives 2 blocks at the same time**

Reordering the last one or two blocks is not uncommon and is well catered for. So I suspect block ordering is not a primary factor in choosing block intervals. The Bitcoin design allows for each node's initial ordering to be somewhat arbitrary. Consider the effect of physical (or effective) distance etc on message propagation times from two distant miners to two other nodes of varying distance.

---

## What did Nakamoto say in 2008?

The Bitcoin white paper has only one mention of "10 minutes":

> If we suppose blocks are
> generated every 10 minutes, 80 bytes \* 6 \* 24 \* 365 = 4.2MB per year. With computer systems
> typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
> 1.2GB per year, storage should not be a problem even if the block headers must be kept in
> memory.

So the block interval is associated with the storage burden on ordinary nodes.

Earlier in the whitepaper, Nakamoto writes

> Nodes always consider the longest chain to be the correct one and will keep working on
> extending it. If two nodes broadcast different versions of the next block simultaneously, some
> nodes may receive one or the other first. In that case, they work on the first one they received,
> but save the other branch in case it becomes longer. The tie will be broken when the next proof-
> of-work is found and one branch becomes longer; the nodes that were working on the other
> branch will then switch to the longer one.

So this kind of activity is allowed for in the design and is not the alleged "huge problem".


---

