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?
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.
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.