<p>I think the question isn't so much whether this is possible, but whether this is desirable.</p>

<p>The block rate limit has several functions:</p>

<ul>
<li>Keeping the stale block rate low, so that the effort a collusion attacker has to do is not much higher than honest miners (per block).</li>
<li>Keeping validation on non-mining full nodes feasible.</li>
</ul>

<p>The second of these goals is inherently hard to achieve without a clock (it could be integrated into your proposal by modulating block size based on the achieved block rate, but that again would introduce the need for a clock).</p>

<p>However, the first of these is also incompatible. A collusion attacker (someone who only mines on top of his own blocks, and ignores anyone else's), or a cartel of miners that collude against everyone else together, can set the block rate arbitrarily high while keeping the uncles rate zero (or whatever desired rate). If such an attacker drives up the block rate high enough, it becomes harder for honest other miners to participate, even when the attacker has less than 50% of the hashrate - the other miners are inherently disadvantaged by only seeing blocks with a delay (the ratio between delay and block interval affects their profitability).</p>

<p>So what this accomplishes is that it self-selects for a set of miners that can keep up with the intended uncle rate, which may be arbitrarily small. The desired property is subtly different: keeping the fork rate low <em>when an acceptably distributed set of non-trusting miners can participate</em>.</p>

CC BY-SA 4.0
2020-05-29T20:38:17.650Z
2020-05-29T20:46:10.020Z
2020-05-29T20:46:10.020Z
Pieter Wuille
<p>No. Without a timestamp being part of the blockchain in some way, it would be impossible for new nodes to sync and converge on the same network difficulty as nodes that have been online. Besides the fact that all stale blocks would need to be saved and relayed (which would be a ton of duplicated and useless data), those blocks would need to have an attached timestamp, or something to indicate the rate of those blocks, which inherently requires a reference to real time.</p>

<p>Furthermore, how would the network agree on the rate of stale blocks? Nodes receive blocks at different times due to external factors, so it's unlikely that all nodes would agree on the rate of stale blocks. To agree would require a timestamp in the block.</p>

CC BY-SA 4.0
2020-05-29T17:01:06.420Z
Uncle blocks are committed to, so the network work can agree on them.
Pieter Wuille
CC BY-SA 4.0
2020-05-29T04:19:47.070Z
2020-05-29T04:19:47.070Z
Ava Chow
<p>Bitcoin is supposed to be a clock on it's own right so it always felt sketchy to me that outside time is referenced. Could bitcoin be aware of it's own block interval through something like uncle block rate? Could that allow it to do difficulty adjustment without reference to outside time?</p>

CC BY-SA 4.0
2020-05-29T00:27:04.417Z
I don't know what "staleblock rate" means.  If your question had details, such as a rough idea of what it means and how it might be used to perform the same functions that timestamps do, then your question would show some research, which makes for better questions. Describing your understanding of what timestamps provide would also be helpful.  Think of a question as an opportunity to teach what you already know and pinpoint exactly what you don't yet know.
Dave Scotese
CC BY-SA 4.0
2020-05-29T01:25:27.873Z
Timestamps make difficulty adjustment possible. I meant uncle blocks not staleblocks to be more precise.  If there are lot of uncle blocks it means block interval is small. Could the difficulty adjustment just target uncle rate and have no reference to timestamps at all?
veoex
CC BY-SA 4.0
2020-05-29T03:58:22.360Z
What are uncle blocks? Bitcoin doesn't have uncle blocks. Stale block rate seems to be the correct term as it seems like you are referring to those blocks which are valid but do not become part of the main chain. Those blocks are also referred to as orphan blocks.
Ava Chow
CC BY-SA 4.0
2020-05-29T05:11:01.087Z
Yeah I meant uncle blocks like in ethereum where you get reward for referencing its header in the next block header. That way you would get the rate and could target it.
veoex
<difficulty><timestamp><difficulty-retargetting>
Does Cryptocurrency really need timestamps?
veoex
# Does Cryptocurrency really need timestamps?

(Asked by: username_0 on 2020-05-26)

Bitcoin is supposed to be a clock on it's own right so it always felt sketchy to me that outside time is referenced. Could bitcoin be aware of it's own block interval through something like uncle block rate? Could that allow it to do difficulty adjustment without reference to outside time?

**Tags:** difficulty, timestamp, difficulty-retargetting

> **Comments:**
> **username_1**: I don't know what "staleblock rate" means.  If your question had details, such as a rough idea of what it means and how it might be used to perform the same functions that timestamps do, then your question would show some research, which makes for better questions. Describing your understanding of what timestamps provide would also be helpful.  Think of a question as an opportunity to teach what you already know and pinpoint exactly what you don't yet know.  
> **username_0**: Timestamps make difficulty adjustment possible. I meant uncle blocks not staleblocks to be more precise.  If there are lot of uncle blocks it means block interval is small. Could the difficulty adjustment just target uncle rate and have no reference to timestamps at all?  
> **username_2**: What are uncle blocks? Bitcoin doesn't have uncle blocks. Stale block rate seems to be the correct term as it seems like you are referring to those blocks which are valid but do not become part of the main chain. Those blocks are also referred to as orphan blocks.  
> **username_0**: Yeah I meant uncle blocks like in ethereum where you get reward for referencing its header in the next block header. That way you would get the rate and could target it.  

---

## 2 answers

### Answer by username_3 on 2020-05-29. Score: 4

I think the question isn't so much whether this is possible, but whether this is desirable.

The block rate limit has several functions:

* Keeping the stale block rate low, so that the effort a collusion attacker has to do is not much higher than honest miners (per block).
* Keeping validation on non-mining full nodes feasible.

The second of these goals is inherently hard to achieve without a clock (it could be integrated into your proposal by modulating block size based on the achieved block rate, but that again would introduce the need for a clock).

However, the first of these is also incompatible. A collusion attacker (someone who only mines on top of his own blocks, and ignores anyone else's), or a cartel of miners that collude against everyone else together, can set the block rate arbitrarily high while keeping the uncles rate zero (or whatever desired rate). If such an attacker drives up the block rate high enough, it becomes harder for honest other miners to participate, even when the attacker has less than 50% of the hashrate - the other miners are inherently disadvantaged by only seeing blocks with a delay (the ratio between delay and block interval affects their profitability).

So what this accomplishes is that it self-selects for a set of miners that can keep up with the intended uncle rate, which may be arbitrarily small. The desired property is subtly different: keeping the fork rate low *when an acceptably distributed set of non-trusting miners can participate*.


---

### Answer by username_2 on 2020-05-29. Score: 1

No. Without a timestamp being part of the blockchain in some way, it would be impossible for new nodes to sync and converge on the same network difficulty as nodes that have been online. Besides the fact that all stale blocks would need to be saved and relayed (which would be a ton of duplicated and useless data), those blocks would need to have an attached timestamp, or something to indicate the rate of those blocks, which inherently requires a reference to real time.

Furthermore, how would the network agree on the rate of stale blocks? Nodes receive blocks at different times due to external factors, so it's unlikely that all nodes would agree on the rate of stale blocks. To agree would require a timestamp in the block.

> **Comments:**
> **username_3**: Uncle blocks are committed to, so the network work can agree on them.  

---

