<p>It's not trivial a) to agree on the time in a distributed system, especially how much time has passed between two events, b) to establish when exactly a block candidate was found. Further, when a node is catching up with the chaintip after being offline, it has no means whatsoever to determine whether a block was actually found within the allocated timeframe.</p>
<p>So now, instead of someone finding a block and announcing it, we need to send around a lot more data, and then run some sort of consensus algorithm to agree whether/which candidates were submitted in time.</p>
<hr />
<blockquote>
<p>But sadly I still do not see how a target difficulty is required for consensus.</p>
</blockquote>
<p>Without difficulty, it becomes subjective if the next block has been found because the criteria is no longer binary. If any difficulty is acceptable, we'd be finding billions of blocks every moment. Let's say all these block announcements cascade through the network. Every node now gets multiple announcements and does unnecessary block validation, even if they only forward the best block they've seen so far at the given height.  How do miners know when they should switch to the next height? How do they know they have seen the best block at the height already? Reorgs would be happening all the time. If the miners are constantly switching the previous block of their block templates to update to the latest state, they'll be almost entirely mining block candidates that will not be compatible with the final best chain. Most of the proof of work would be entirely wasted and would not contribute to the security of the network at all. Additionally, the bandwidth load on the network would drastically increase to gossip all the blocks.</p>
<p>Especially miners with larger shares of the hash power now have all sorts of additional angles to attack the previous block rather than moving forward, e.g. selfish mining and Finney attacks become easier. Getting rid of the difficulty would hamper progress of the blockchain and would make even multiple confirmations unreliable.</p>

CC BY-SA 4.0
2021-08-02T00:35:41.687Z
Why doesn't just PoW suffice for that consensus? As long as nodes have a roughly synchronized clock, the time a block was mined could be computed by `genesis_time + 10 mins * block_count`. Nodes just broadcast blocks as usual and pick the chain with the largest work.
MaiaVictor
CC BY-SA 4.0
2021-08-02T00:38:32.280Z
Let's assume I'm a miner and I see that the PoW in the last ten minutes was pretty low, so I continue to mine for a bit and fudge the timestamp on my block candidates. When I do find a block with a higher PoW, I announce it to the network. How do you distinguish whether my block candidate was found in time or not?
Murch
CC BY-SA 4.0
2021-08-02T00:40:33.443Z
If every node decides for itself, you have now a great way to split the network. If the nodes decide together, you need a consensus algorithm.
Murch
CC BY-SA 4.0
2021-08-02T18:18:46.063Z
How do you propose to enforce the "best block within a time span of ten minutes" without timestamps?
Murch
CC BY-SA 4.0
2021-08-02T18:35:17.950Z
@Murch there is no timestamp. But yes, you could "re-mine" old blocks if you wanted to. But you'd still need to provide all the newer blocks, with more accumulated work, for it to be accepted. Re-mining sufficiently old blocks would be infeasible, so, ultimately, nodes do reach a consensus w.r.t. the canonical chain, exactly like on Bitcoin, no? What I'm saying is: I still don't see why a target difficulty, rather than just collecting blocks and computing the largest chain, is required for that.
MaiaVictor
CC BY-SA 4.0
2021-08-02T18:36:31.293Z
@MaiaVictor: If I had a solid attack on SHA-256 I'd prefer to announce it by rolling back ransomware transactions that way.
Joshua
CC BY-SA 4.0
2021-08-02T18:47:00.860Z
If you don't have a difficulty, how do you determine the PoW that was done? Just by the lowest hash?
Murch
CC BY-SA 4.0
2021-08-02T18:49:56.750Z
If so, no, it's not finding the best chain like Bitcoin. For example a malicious miner can try sending money to themselves in every block that they mine. When they find an extremely low hash, they keep that block secret and make a conflicting transaction sending that same money to an exchange. They let their deposit get a couple confirmations and then trade it for an alternative currency. Then the attacker publishes their block with an extremely low hash to replace the previous best chain.
Murch
CC BY-SA 4.0
2021-08-02T18:58:08.243Z
While blocks that are buried are still hard to replace, the chaintip becomes completely unreliable.
Murch
CC BY-SA 4.0
2021-08-02T19:10:34.723Z
@Murch yes, lowest hash. That is exactly what I mean. Bitcoin's chaintip isn't 100% reliable either, you need ~6 confs for maximum security. In such proposal, the finality time should be considered to be quite large (say, 24h). My point is: it *would* work as a consensus algorithm, it would just be less efficient for finality than Bitcoin, but would be arguably simpler to implement, and more secure to against [these several target-difficulty-related attacks](https://old.reddit.com/r/Bitcoin/comments/mtugta/mentor_monday_april_19_2021_ask_all_your_bitcoin/gv86j6b/). Does that make sense?
MaiaVictor
CC BY-SA 4.0
2021-08-02T19:16:28.883Z
I don't understand how you arrived at that assessment. I think it would be much less secure since most of the hashrate is now wasted on unnecessary competition rather than progress, it would require way more confirmations to safely transact, it would become an art to assess whether the current best block should still be competed with or settled for as the prev best block, it would be way more inefficient in bandwidth and computing power for participating nodes. It's not clear to me in what way the proposed approach is better at all.
Murch
CC BY-SA 4.0
2021-08-02T20:06:07.533Z
I see, now these are interesting points to keep in mind. I'm not sure if what you're saying really holds, i.e., if most of the computing power would be wasted, and if it is really hard to define which block to mine upon. But these are sensible points to consider. Thanks for the inputs.
MaiaVictor
CC BY-SA 4.0
2021-08-03T00:04:49.467Z
@MaiaVictor: Riddle me this: if you were a small miner on the network, and found a block with difficulty of 1/100th of the current hashrate. Would you a) broadcast it and try to mine on top of it or b) try to mine a better block at the same height? As another miner, when you receive a block at 1/100th of the current hashrate, would you a) switch to using that as the previous block, b) try to mine a better blocks?
Murch
CC BY-SA 4.0
2021-08-03T00:07:46.280Z
What if you receive five blocks with 1/100th of the difficulty building on top of each other within one minute? Would you build on top of that, or continue to try a single block with 1/10th the difficulty to replace all of them?
Murch
CC BY-SA 4.0
2021-08-03T00:34:57.980Z
I think you'll always be mining on top of the best block for the last 10 mins period, trying to get smaller and smaller hashes, and broadcasting the best block you have (even if it isn't yours). As long as miners keep doing that, blocks with low difficulty will just not propagate, and good blocks will reach everyone. After the 10 mins mark, miners would start mining on top of the best block they have for the latest 10 minutes period, which will almost always be the right one. If it isn't, soon enough the right one will arrive and they won't have wasted that much effort.
MaiaVictor
CC BY-SA 4.0
2021-08-03T00:35:59.150Z
Of course, you can try to re-mine older blocks, but that makes it much less likely that your blocks will propagate, so you have incentive to always mine on top of your best block, i.e., your tip with the most accumulated PoW.
MaiaVictor
CC BY-SA 4.0
2021-08-03T00:41:51.003Z
"I think you'll always be mining on top of the best block for the last 10 mins period" ⇒ It's not clear why you believe that miners would converge on this particular behavior. Trivial counterexample: A miner finds an extremely low hash. The most rational thing would be to immediately start mining on top of it, perhaps even keep it secret for a while to make other miners waste their mining power.
Murch
CC BY-SA 4.0
2021-08-03T00:43:54.070Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/128161/discussion-between-murch-and-maiavictor).
Murch
CC BY-SA 4.0
2021-08-02T00:09:02.570Z
2021-08-02T19:09:56.643Z
2021-08-02T19:09:56.643Z
Murch
<p>The key point of the Bitcoin design is to create a system that provides a reliable transaction record <em>without any central coordination or arbiter</em>. Instead, Bitcoin is a distributed system where a consensus is reached using a &quot;consensus algorithm&quot; that can be repeatedly evaluated by every node on the network.</p>
<p>As Bitcoin is operating today, the target of a &quot;block period&quot; is well-defined and agreed upon by all nodes. A node can verify whether a certain block is a valid solution using just knowledge from the chain (i.e. the target difficulty) without relying on any clock.</p>
<p>In the system you propose, you can't decide whether you have seen &quot;the best block of the 10-minute timespan&quot; by just looking at the block. This means you don't know whether that block is a valid block without knowing all other candidates. The consequence is that a block you considered valid might become invalid when a block with a lower hash appears. This is something that can not happen according to the current scheme, and it has dramatic consequences. Today, a block that is considered valid can safely be mined upon, as the work required to outrun the valid block is expected to be around the same as continuing on that block. In your scheme, it takes just the work of finding a better block to make the previously accepted solution <em>invalid</em> and you destroy the work based on that now invalid block &quot;for free&quot;.</p>
<p>So when you start mining on a block, you need to be confident that you know a valid solution, and that this solution <em>will stay valid</em>. The usual approach to the challenge would be a central arbiter that collects candidates and decides which block to pick and fixes this decision for good. As I already stated in the introduction, anything relying on a central trustworthy service doesn't meet the primary goal of Bitcoin.</p>

CC BY-SA 4.0
2021-08-02T18:31:38.830Z
*In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block.* -- How so? The best block is the one with the highest PoW. In Bitcoin, you, too, can't tell whether you have seen the correct block in a 10-minute timespan, without knowing all blocks: two blocks could have been mined simultaneously. The dispute is resolved after more blocks. The exact same process takes place in my system, by just picking the chain with the largest PoW to begin with. There is no central coordinator involved.
MaiaVictor
CC BY-SA 4.0
2021-08-02T18:52:49.337Z
My point was to answer the question: "can you decide whether a block *can* be a valid solution". In the proposed system, *every* block can be a valid solution. In the current system, only blocks hitting the target can be a valid solution. Because finding blocks that hit the target is extremely rare, usually only one block that solves a given depth is ever calculated and can easily be identified (by it hitting the target). In the proposed system, you can't easily identify whether a block you get shown is *most likely* the generally accepted block at that depth.
Michael Karcher
CC BY-SA 4.0
2021-08-02T19:15:22.037Z
Ah, fair enough, but why is that important or desirable? Do you mean as a way to prevent flood/spam? It is fair that you can't know if a block is valid, but for all practical purposes you can make very good guesses. For example, if you received a block with a large PoW score, you could probably ignore any block with <50% of its PoW score.
MaiaVictor
CC BY-SA 4.0
2021-08-02T21:43:10.810Z
I edited my answer to focus on the "beating one old block invalidates  whole chain of blocks" issue, which is actually the core behind the "is this block valid" question.
Michael Karcher
CC BY-SA 4.0
2021-08-02T21:47:55.430Z
I appreciate your answer, it is turning great, but I still have a few concerns. 1. *"Today, a block that is considered valid can safely be mined upon"* - safely in what sense? In Bitcoin, it can also happen that you're mining upon a block that becomes invalid, if that block becomes an uncle. 2. *"The usual approach to the challenge would be a central arbiter that collects candidates and decides which block to pick and fixes this decision for good."* That doesn't make sense to me. Instead, you'd just mine the topmost block and hope it doesn't become invalid, in your words. Makes sense?
MaiaVictor
CC BY-SA 4.0
2021-08-02T21:53:33.603Z
The main difference is that currently a chain gets orphaned if someone presents a longer chain, which needs much work as the orphan chain. Your scheme allows attacking just one block, the weakest link, to take down the whole chain depending on it, because a previously valid block ("lowest hash") now obviously isn't valid anymore ("it's just the second-lowest hash, sorry"), and you don't have to beat the chain following this block.
Michael Karcher
CC BY-SA 4.0
2021-08-02T21:56:04.373Z
So my key point is "orphaned valid forks of the chain are OK, blocks that suddenly turn out invalid break the scheme." - so validness of a block must be a property that can't dynamically changem
Michael Karcher
CC BY-SA 4.0
2021-08-02T22:01:37.320Z
Yes, that is a point, but note that you pick the longest chain by the sum of the work of every block, so just selecting a block with small score to replace won't work, as you also need to replace every block on top of it. I.e., a valid block doesn't turn invalid if a block with same height but higher score shows up. Every block is valid, you just pick the longest chain as the canonical timeline by summing the individual scores.
MaiaVictor
CC BY-SA 4.0
2021-08-02T22:08:36.293Z
That's not what your question says. It says that every ten minutes, the block with the lowest hash gets accepted (and all other blocks obviously need to rejected). So it's not "most expensive chain wins", but the chain with the more expensive block at the split point wins.
Michael Karcher
CC BY-SA 4.0
2021-08-02T22:11:05.970Z
Ah, that's how you interpreted it? That is not what I meant. I can see the issue now, and indeed my question is ill phrased. I meant that every block is accepted, but the chain with largest accumulated work is the canonical one.
MaiaVictor
CC BY-SA 4.0
2021-08-03T00:49:47.280Z
For the record, I was assuming greatest sum of work, but the same problem still applies to the last few blocks at the chaintip: A single block with a very low hash could reorganize one or more blocks from the chaintip, accidentally or on purpose.
Murch
CC BY-SA 4.0
2021-08-03T08:32:31.267Z
@Murch I fail to see that as a breaking issue, though. If the block with a very low hash is able to replace the chain tip, this block plus its descendants are still expected to have taken more work than the current chaintip, so this is in line with the bitcoin idea: The majority of hashing power is right. A soft issue with the proposed scheme is that reorganizations will happen more often until a consensus for a specific block is found, so less work goes into the final chain as more work is spent on loosing chains.
Michael Karcher
CC BY-SA 4.0
2021-08-03T08:40:49.807Z
(and it seems my last comment is in line with your answer. It depends on how you look at it whether "no difficulty" will just be a worse but workable scheme with many reoganizaions and higher risks of underhanded attacks or these risks make that scheme unacceptable. I agree with you that reorganizations after nearly every block and the bandwidth increase are not desireable properties)
Michael Karcher
CC BY-SA 4.0
2021-08-03T16:26:38.567Z
Yeah, it's not a complete no-go, but it would make Bitcoin less secure because a majority attack (that always builds on their own chain) would require a much smaller portion of the total hashrate to pull ahead, because so much hashing is wasted on furthering stale tips. It would also be a terrible experience from the perspective of users waiting for confirmations of their transactions.
Murch
CC BY-SA 4.0
2021-08-02T10:25:50.887Z
2021-08-02T21:40:47.917Z
2021-08-02T21:40:47.917Z
Michael Karcher
<p>Two potential problems with this idea, somewhat related.</p>
<ol>
<li><p>Mining incentives will fluctuate during the 10-minute period, depending on the difficulty of the current block &quot;candidate&quot;. If it is higher than expected, miners will be incentivised to stop mining until the start of the next period. In an extreme case, it might be that all miners stop mining for the rest of the period because the probability of mining the canonical block makes it unprofitable for all miners.</p>
</li>
<li><p>At the beginning of each 10-minute period, the relay network would be flooded with block &quot;candidates&quot;. Because the current best block for the new period is likely to have a relatively low-difficulty hash, many new best-blocks are being generated in quick succession, and this could overload relay nodes. This could affect both network bandwidth (receiving blocks) and CPU (validating blocks as they arrive).</p>
</li>
</ol>
<p>The existing bitcoin mining difficulty scheme does not suffer from these problems because the expected rate of new block generation is constant.</p>

CC BY-SA 4.0
2021-08-16T22:25:45.967Z
Good points. Also appreciate this answer as it understands what I proposed.
MaiaVictor
CC BY-SA 4.0
2021-08-04T11:48:13.623Z
2021-08-04T11:48:13.623Z
QMdEW4pbr
<h2>Recap</h2>
<p>The difficulty was designed by Satoshi to balance the network and guarantee <em>equal</em> access to new peers, preventing malicious third parties to control the network, filter transaction and obtain the generated coins too easily.</p>
<p>The PoW is a mathematical proof that someone spent resources to gain the generated coins. If there was no PoW, an organized entity with a lot of resources, e.g. a botnet or an ISP, would spam the network with transactions that drive interest to them.</p>
<p>In particular, for larger transactions (1), we need to be particularly sure that Alice (malicious spender) does not issue a transaction to Bob, which sells goods, and then spams the network with transaction to merchant Charlie or to themselves to fraud Bob.</p>
<h2>Answering (or trying to)</h2>
<p>Consider that Bitcoin is totally decentralized and distributed systems suffer the concept of time, which is not absolute. If you have questions on that you should post on SW Engineering. I'll just say &quot;without a certification authority you can hold a message forever&quot;. And Bitcoin refuses certification authorities that can be hacked/bribed/forced-by-government etc.</p>
<p>Satoshi needed to design a system so that sequential transactions could not (that easily) be rewritten (2).</p>
<blockquote>
<p>Suppose that Bitcoin nodes just accepted the block with the largest PoW every 10 minutes.</p>
</blockquote>
<p>The very problem is: look it not from the perspective of the whole system. Look it from the perspective of <strong>my</strong> Bitcoin-qt client bootstrapping right now from void.</p>
<p>How can my client be sure that <strong>nobody is retaining blocks</strong>? How can my client be sure about the network size judging from the input of other malicious peers?</p>
<p>Satoshi expected the network to grow and the computational power along with it. With more mining nodes, a larger number of blocks would hit the difficulty treshold in less than 10 minutes.</p>
<p>From the perspective of a <strong>lonely</strong> node, which is the very concept of peer-to-peer networks, the target is not to identify the block with the largest difficulty, which would be difficult if peers try to hide information, but look for <strong>the longest chain</strong></p>
<p>The longest-chain principle does not prevent Alice completely from rewriting a transaction. It makes it so expensive that, at least for grocery purchases, it's worth following the rules than cheating.</p>
<p>And is the very reason why peers require 3 or more confirmations to consider a transaction <em>final</em>.</p>
<p>(1) Bitcoin was designed in order both to buy grocery and real estate. Of course, it's not that loss a double spend at the grocery</p>
<p>(2) Rewriting a transaction, in the scope of a blockchain, means that if transaction occurred at block <code>100</code>, replacing every block from <code>100</code> to <code>current</code> with <code>100</code><sup>1</sup> to <code>current</code><sup>1</sup></p>

CC BY-SA 4.0
2021-08-02T18:28:49.150Z
*How can my client be sure that nobody is retaining blocks?* -- You can't be sure of that in Bitcoin either. There could very well be fork with more work (a "longest chain") that you're not aware of. Bitcoin nodes just assume they've met enough collaborating peers to get that data. My proposed system does the same. The only difference is that, instead of a target difficulty, the node just picks the block with largest work. For the PoV of a lone node, it just collects blocks and computes the longest chain of the blocks it does see. It doesn't need a central party in any form to reach consensus.
MaiaVictor
CC BY-SA 4.0
2021-08-02T13:13:03.527Z
2021-08-02T13:13:03.527Z
usr-local-ΕΨΗΕΛΩΝ
<p>Suppose that Bitcoin nodes had no target difficulty at all, and instead just accepted the block with the largest PoW every 10 minutes. Ignoring the increased bandwidth (since nodes would be broadcasting several block candidates), would this work? Or is there some technical need for an adjustable target difficulty?</p>
<p>Edit: to clarify, I meant that every block is accepted, but only the chain with the largest accumulated work is considered canonical. I.e., if there is a weak block days ago, and you mine a block with higher score, that weak block does not become invalid. You need to replace every block on top of it if you want to rewrite the story that far. I.e., it is the same as Bitcoin, without a target difficulty. Nodes just accept all blocks, and compute the best block by summing the accumulated work of each candidate tip.</p>

CC BY-SA 4.0
2021-08-02T18:40:14.237Z
I've got 3 great answers, thanks! But sadly I still do not see how a target difficulty is required for consensus. You're for some reason implying that, without a target difficulty, we'd need a central coordinator for consensus. But that does not seem to be true: as long as nodes collect blocks and compute the chain with the most accumulated work, they will reach consensus w.r.t. canonical chain. Yes, we must assume that we're able to get the data from non-malicious peers, but Bitcoin also assumes that!
MaiaVictor
CC BY-SA 4.0
2021-08-02T19:52:42.610Z
What's a "largest PoW" ? The amount of work done on a block to hash it is pretty much the same as any other block, so how do you assert that the work done is larger for this than that?
Caius Jard
CC BY-SA 4.0
2021-08-02T20:03:29.927Z
By the value of the block hash. You can assign a block score as `1 / block_hash`, which is an estimative of how many nonces were attempted to make this block. Then, the sum of all block hashes up to root is the score of this specific chain. Nodes just receive blocks and select the chain with largest score.
MaiaVictor
CC BY-SA 4.0
2021-08-02T20:21:36.527Z
*how many nonces were attempted to make this block* - whut?
Caius Jard
CC BY-SA 4.0
2021-08-02T20:33:51.880Z
It is a simple sentence. What part are you having trouble understanding?
MaiaVictor
CC BY-SA 4.0
2021-08-02T20:46:09.320Z
The part where you asserted that a block hash value is in any way related to the number of nonces that were tried in order to realize a hash that is smaller than the difficulty. A miner could get lucky and pack a block that hashes to lower than the difficulty on the first go, or it could get unlucky and chew through a billion block variations before it achieves the same
Caius Jard
CC BY-SA 4.0
2021-08-02T20:59:26.430Z
Good question! Turns out it **is** related, statistically. Of course, you can't determine how many nonces were actually attempted to produce a specific block, since, as you've noticed, a lucky miner could get a very low hash on the first attempt. But it is possible to **estimate** - mind the keyword. For example, if the first 4 bits of a hash are 0, you can assume it took at least 16 hashes to produce it. Of course, that may not be the case for a specific block, but, on average, this statistic holds. Makes sense?
MaiaVictor
CC BY-SA 4.0
2021-08-02T22:20:33.440Z
Current bitcoin doesn't add (estimated) accumulated work to choose a chain, but it just counts chain length. It works as easy substitute for accumulated work, because nearly every block is near the target difficulty. In your scheme, actual work estimation needs to be implemented, but on first look, it might work, too.
Michael Karcher
CC BY-SA 4.0
2021-08-02T22:24:47.900Z
Oh, I didn't know that, but makes sense that BTC doesn't need to sum the work as I describe.
MaiaVictor
CC BY-SA 4.0
2021-08-02T23:36:39.840Z
@MichaelKarcher: Bitcoin looks for the chaintip with the most work: https://github.com/bitcoin/bitcoin/blob/4b1fb50def0dea0cd320bc43c12d9a12edde0390/src/validation.cpp#L2399. The original release had the bug that it only compared the length, but this would have allowed long-range low difficulty reorg attacks and was fixed many years ago.
Murch
<mining-theory><difficulty><proof-of-work><consensus>
Would Bitcoin still work without a target difficulty?
MaiaVictor
# Would Bitcoin still work without a target difficulty?

(Asked by: username_0 on 2021-08-01)

Suppose that Bitcoin nodes had no target difficulty at all, and instead just accepted the block with the largest PoW every 10 minutes. Ignoring the increased bandwidth (since nodes would be broadcasting several block candidates), would this work? Or is there some technical need for an adjustable target difficulty?

Edit: to clarify, I meant that every block is accepted, but only the chain with the largest accumulated work is considered canonical. I.e., if there is a weak block days ago, and you mine a block with higher score, that weak block does not become invalid. You need to replace every block on top of it if you want to rewrite the story that far. I.e., it is the same as Bitcoin, without a target difficulty. Nodes just accept all blocks, and compute the best block by summing the accumulated work of each candidate tip.

**Tags:** mining-theory, difficulty, proof-of-work, consensus

> **Comments:**
> **username_0**: I've got 3 great answers, thanks! But sadly I still do not see how a target difficulty is required for consensus. You're for some reason implying that, without a target difficulty, we'd need a central coordinator for consensus. But that does not seem to be true: as long as nodes collect blocks and compute the chain with the most accumulated work, they will reach consensus w.r.t. canonical chain. Yes, we must assume that we're able to get the data from non-malicious peers, but Bitcoin also assumes that!  
> **username_1**: What's a "largest PoW" ? The amount of work done on a block to hash it is pretty much the same as any other block, so how do you assert that the work done is larger for this than that?  
> **username_0**: By the value of the block hash. You can assign a block score as `1 / block_hash`, which is an estimative of how many nonces were attempted to make this block. Then, the sum of all block hashes up to root is the score of this specific chain. Nodes just receive blocks and select the chain with largest score.  
> **username_1**: *how many nonces were attempted to make this block* - whut?  
> **username_0**: It is a simple sentence. What part are you having trouble understanding?  
> **username_1**: The part where you asserted that a block hash value is in any way related to the number of nonces that were tried in order to realize a hash that is smaller than the difficulty. A miner could get lucky and pack a block that hashes to lower than the difficulty on the first go, or it could get unlucky and chew through a billion block variations before it achieves the same  
> **username_0**: Good question! Turns out it **is** related, statistically. Of course, you can't determine how many nonces were actually attempted to produce a specific block, since, as you've noticed, a lucky miner could get a very low hash on the first attempt. But it is possible to **estimate** - mind the keyword. For example, if the first 4 bits of a hash are 0, you can assume it took at least 16 hashes to produce it. Of course, that may not be the case for a specific block, but, on average, this statistic holds. Makes sense?  
> **username_2**: Current bitcoin doesn't add (estimated) accumulated work to choose a chain, but it just counts chain length. It works as easy substitute for accumulated work, because nearly every block is near the target difficulty. In your scheme, actual work estimation needs to be implemented, but on first look, it might work, too.  
> **username_0**: Oh, I didn't know that, but makes sense that BTC doesn't need to sum the work as I describe.  
> **username_3**: @username_2: Bitcoin looks for the chaintip with the most work: https://github.com/bitcoin/bitcoin/blob/4b1fb50def0dea0cd320bc43c12d9a12edde0390/src/validation.cpp#L2399. The original release had the bug that it only compared the length, but this would have allowed long-range low difficulty reorg attacks and was fixed many years ago.  

---

## 4 answers

### Answer by username_3 on 2021-08-02. Score: 7

It's not trivial a) to agree on the time in a distributed system, especially how much time has passed between two events, b) to establish when exactly a block candidate was found. Further, when a node is catching up with the chaintip after being offline, it has no means whatsoever to determine whether a block was actually found within the allocated timeframe.

So now, instead of someone finding a block and announcing it, we need to send around a lot more data, and then run some sort of consensus algorithm to agree whether/which candidates were submitted in time.

---

> But sadly I still do not see how a target difficulty is required for consensus.

Without difficulty, it becomes subjective if the next block has been found because the criteria is no longer binary. If any difficulty is acceptable, we'd be finding billions of blocks every moment. Let's say all these block announcements cascade through the network. Every node now gets multiple announcements and does unnecessary block validation, even if they only forward the best block they've seen so far at the given height. How do miners know when they should switch to the next height? How do they know they have seen the best block at the height already? Reorgs would be happening all the time. If the miners are constantly switching the previous block of their block templates to update to the latest state, they'll be almost entirely mining block candidates that will not be compatible with the final best chain. Most of the proof of work would be entirely wasted and would not contribute to the security of the network at all. Additionally, the bandwidth load on the network would drastically increase to gossip all the blocks.

Especially miners with larger shares of the hash power now have all sorts of additional angles to attack the previous block rather than moving forward, e.g. selfish mining and Finney attacks become easier. Getting rid of the difficulty would hamper progress of the blockchain and would make even multiple confirmations unreliable.

> **Comments:**
> **username_0**: Why doesn't just PoW suffice for that consensus? As long as nodes have a roughly synchronized clock, the time a block was mined could be computed by `genesis_time + 10 mins * block_count`. Nodes just broadcast blocks as usual and pick the chain with the largest work.  
> **username_3**: Let's assume I'm a miner and I see that the PoW in the last ten minutes was pretty low, so I continue to mine for a bit and fudge the timestamp on my block candidates. When I do find a block with a higher PoW, I announce it to the network. How do you distinguish whether my block candidate was found in time or not?  
> **username_3**: If every node decides for itself, you have now a great way to split the network. If the nodes decide together, you need a consensus algorithm.  
> **username_3**: How do you propose to enforce the "best block within a time span of ten minutes" without timestamps?  
> **username_0**: @username_3 there is no timestamp. But yes, you could "re-mine" old blocks if you wanted to. But you'd still need to provide all the newer blocks, with more accumulated work, for it to be accepted. Re-mining sufficiently old blocks would be infeasible, so, ultimately, nodes do reach a consensus w.r.t. the canonical chain, exactly like on Bitcoin, no? What I'm saying is: I still don't see why a target difficulty, rather than just collecting blocks and computing the largest chain, is required for that.  
> **username_4**: @username_0: If I had a solid attack on SHA-256 I'd prefer to announce it by rolling back ransomware transactions that way.  
> **username_3**: If you don't have a difficulty, how do you determine the PoW that was done? Just by the lowest hash?  
> **username_3**: If so, no, it's not finding the best chain like Bitcoin. For example a malicious miner can try sending money to themselves in every block that they mine. When they find an extremely low hash, they keep that block secret and make a conflicting transaction sending that same money to an exchange. They let their deposit get a couple confirmations and then trade it for an alternative currency. Then the attacker publishes their block with an extremely low hash to replace the previous best chain.  
> **username_3**: While blocks that are buried are still hard to replace, the chaintip becomes completely unreliable.  
> **username_0**: @username_3 yes, lowest hash. That is exactly what I mean. Bitcoin's chaintip isn't 100% reliable either, you need ~6 confs for maximum security. In such proposal, the finality time should be considered to be quite large (say, 24h). My point is: it *would* work as a consensus algorithm, it would just be less efficient for finality than Bitcoin, but would be arguably simpler to implement, and more secure to against [these several target-difficulty-related attacks](https://old.reddit.com/r/Bitcoin/comments/mtugta/mentor_monday_april_19_2021_ask_all_your_bitcoin/gv86j6b/). Does that make sense?  
> **username_3**: I don't understand how you arrived at that assessment. I think it would be much less secure since most of the hashrate is now wasted on unnecessary competition rather than progress, it would require way more confirmations to safely transact, it would become an art to assess whether the current best block should still be competed with or settled for as the prev best block, it would be way more inefficient in bandwidth and computing power for participating nodes. It's not clear to me in what way the proposed approach is better at all.  
> **username_0**: I see, now these are interesting points to keep in mind. I'm not sure if what you're saying really holds, i.e., if most of the computing power would be wasted, and if it is really hard to define which block to mine upon. But these are sensible points to consider. Thanks for the inputs.  
> **username_3**: @username_0: Riddle me this: if you were a small miner on the network, and found a block with difficulty of 1/100th of the current hashrate. Would you a) broadcast it and try to mine on top of it or b) try to mine a better block at the same height? As another miner, when you receive a block at 1/100th of the current hashrate, would you a) switch to using that as the previous block, b) try to mine a better blocks?  
> **username_3**: What if you receive five blocks with 1/100th of the difficulty building on top of each other within one minute? Would you build on top of that, or continue to try a single block with 1/10th the difficulty to replace all of them?  
> **username_0**: I think you'll always be mining on top of the best block for the last 10 mins period, trying to get smaller and smaller hashes, and broadcasting the best block you have (even if it isn't yours). As long as miners keep doing that, blocks with low difficulty will just not propagate, and good blocks will reach everyone. After the 10 mins mark, miners would start mining on top of the best block they have for the latest 10 minutes period, which will almost always be the right one. If it isn't, soon enough the right one will arrive and they won't have wasted that much effort.  
> **username_0**: Of course, you can try to re-mine older blocks, but that makes it much less likely that your blocks will propagate, so you have incentive to always mine on top of your best block, i.e., your tip with the most accumulated PoW.  
> **username_3**: "I think you'll always be mining on top of the best block for the last 10 mins period" ⇒ It's not clear why you believe that miners would converge on this particular behavior. Trivial counterexample: A miner finds an extremely low hash. The most rational thing would be to immediately start mining on top of it, perhaps even keep it secret for a while to make other miners waste their mining power.  
> **username_3**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/128161/discussion-between-username_3-and-username_0).  

---

### Answer by username_2 on 2021-08-02. Score: 4

The key point of the Bitcoin design is to create a system that provides a reliable transaction record *without any central coordination or arbiter*. Instead, Bitcoin is a distributed system where a consensus is reached using a "consensus algorithm" that can be repeatedly evaluated by every node on the network.

As Bitcoin is operating today, the target of a "block period" is well-defined and agreed upon by all nodes. A node can verify whether a certain block is a valid solution using just knowledge from the chain (i.e. the target difficulty) without relying on any clock.

In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block. This means you don't know whether that block is a valid block without knowing all other candidates. The consequence is that a block you considered valid might become invalid when a block with a lower hash appears. This is something that can not happen according to the current scheme, and it has dramatic consequences. Today, a block that is considered valid can safely be mined upon, as the work required to outrun the valid block is expected to be around the same as continuing on that block. In your scheme, it takes just the work of finding a better block to make the previously accepted solution *invalid* and you destroy the work based on that now invalid block "for free".

So when you start mining on a block, you need to be confident that you know a valid solution, and that this solution *will stay valid*. The usual approach to the challenge would be a central arbiter that collects candidates and decides which block to pick and fixes this decision for good. As I already stated in the introduction, anything relying on a central trustworthy service doesn't meet the primary goal of Bitcoin.

> **Comments:**
> **username_0**: *In the system you propose, you can't decide whether you have seen "the best block of the 10-minute timespan" by just looking at the block.* -- How so? The best block is the one with the highest PoW. In Bitcoin, you, too, can't tell whether you have seen the correct block in a 10-minute timespan, without knowing all blocks: two blocks could have been mined simultaneously. The dispute is resolved after more blocks. The exact same process takes place in my system, by just picking the chain with the largest PoW to begin with. There is no central coordinator involved.  
> **username_2**: My point was to answer the question: "can you decide whether a block *can* be a valid solution". In the proposed system, *every* block can be a valid solution. In the current system, only blocks hitting the target can be a valid solution. Because finding blocks that hit the target is extremely rare, usually only one block that solves a given depth is ever calculated and can easily be identified (by it hitting the target). In the proposed system, you can't easily identify whether a block you get shown is *most likely* the generally accepted block at that depth.  
> **username_0**: Ah, fair enough, but why is that important or desirable? Do you mean as a way to prevent flood/spam? It is fair that you can't know if a block is valid, but for all practical purposes you can make very good guesses. For example, if you received a block with a large PoW score, you could probably ignore any block with <50% of its PoW score.  
> **username_2**: I edited my answer to focus on the "beating one old block invalidates  whole chain of blocks" issue, which is actually the core behind the "is this block valid" question.  
> **username_0**: I appreciate your answer, it is turning great, but I still have a few concerns. 1. *"Today, a block that is considered valid can safely be mined upon"* - safely in what sense? In Bitcoin, it can also happen that you're mining upon a block that becomes invalid, if that block becomes an uncle. 2. *"The usual approach to the challenge would be a central arbiter that collects candidates and decides which block to pick and fixes this decision for good."* That doesn't make sense to me. Instead, you'd just mine the topmost block and hope it doesn't become invalid, in your words. Makes sense?  
> **username_2**: The main difference is that currently a chain gets orphaned if someone presents a longer chain, which needs much work as the orphan chain. Your scheme allows attacking just one block, the weakest link, to take down the whole chain depending on it, because a previously valid block ("lowest hash") now obviously isn't valid anymore ("it's just the second-lowest hash, sorry"), and you don't have to beat the chain following this block.  
> **username_2**: So my key point is "orphaned valid forks of the chain are OK, blocks that suddenly turn out invalid break the scheme." - so validness of a block must be a property that can't dynamically changem  
> **username_0**: Yes, that is a point, but note that you pick the longest chain by the sum of the work of every block, so just selecting a block with small score to replace won't work, as you also need to replace every block on top of it. I.e., a valid block doesn't turn invalid if a block with same height but higher score shows up. Every block is valid, you just pick the longest chain as the canonical timeline by summing the individual scores.  
> **username_2**: That's not what your question says. It says that every ten minutes, the block with the lowest hash gets accepted (and all other blocks obviously need to rejected). So it's not "most expensive chain wins", but the chain with the more expensive block at the split point wins.  
> **username_0**: Ah, that's how you interpreted it? That is not what I meant. I can see the issue now, and indeed my question is ill phrased. I meant that every block is accepted, but the chain with largest accumulated work is the canonical one.  
> **username_3**: For the record, I was assuming greatest sum of work, but the same problem still applies to the last few blocks at the chaintip: A single block with a very low hash could reorganize one or more blocks from the chaintip, accidentally or on purpose.  
> **username_2**: @username_3 I fail to see that as a breaking issue, though. If the block with a very low hash is able to replace the chain tip, this block plus its descendants are still expected to have taken more work than the current chaintip, so this is in line with the bitcoin idea: The majority of hashing power is right. A soft issue with the proposed scheme is that reorganizations will happen more often until a consensus for a specific block is found, so less work goes into the final chain as more work is spent on loosing chains.  
> **username_2**: (and it seems my last comment is in line with your answer. It depends on how you look at it whether "no difficulty" will just be a worse but workable scheme with many reoganizaions and higher risks of underhanded attacks or these risks make that scheme unacceptable. I agree with you that reorganizations after nearly every block and the bandwidth increase are not desireable properties)  
> **username_3**: Yeah, it's not a complete no-go, but it would make Bitcoin less secure because a majority attack (that always builds on their own chain) would require a much smaller portion of the total hashrate to pull ahead, because so much hashing is wasted on furthering stale tips. It would also be a terrible experience from the perspective of users waiting for confirmations of their transactions.  

---

### Answer by username_5 on 2021-08-04. Score: 2

Two potential problems with this idea, somewhat related.

1. Mining incentives will fluctuate during the 10-minute period, depending on the difficulty of the current block "candidate". If it is higher than expected, miners will be incentivised to stop mining until the start of the next period. In an extreme case, it might be that all miners stop mining for the rest of the period because the probability of mining the canonical block makes it unprofitable for all miners.
2. At the beginning of each 10-minute period, the relay network would be flooded with block "candidates". Because the current best block for the new period is likely to have a relatively low-difficulty hash, many new best-blocks are being generated in quick succession, and this could overload relay nodes. This could affect both network bandwidth (receiving blocks) and CPU (validating blocks as they arrive).

The existing bitcoin mining difficulty scheme does not suffer from these problems because the expected rate of new block generation is constant.

> **Comments:**
> **username_0**: Good points. Also appreciate this answer as it understands what I proposed.  

---

### Answer by username_6 on 2021-08-02. Score: 1

## Recap

The difficulty was designed by Satoshi to balance the network and guarantee *equal* access to new peers, preventing malicious third parties to control the network, filter transaction and obtain the generated coins too easily.

The PoW is a mathematical proof that someone spent resources to gain the generated coins. If there was no PoW, an organized entity with a lot of resources, e.g. a botnet or an ISP, would spam the network with transactions that drive interest to them.

In particular, for larger transactions (1), we need to be particularly sure that Alice (malicious spender) does not issue a transaction to Bob, which sells goods, and then spams the network with transaction to merchant Charlie or to themselves to fraud Bob.

## Answering (or trying to)

Consider that Bitcoin is totally decentralized and distributed systems suffer the concept of time, which is not absolute. If you have questions on that you should post on SW Engineering. I'll just say "without a certification authority you can hold a message forever". And Bitcoin refuses certification authorities that can be hacked/bribed/forced-by-government etc.

Satoshi needed to design a system so that sequential transactions could not (that easily) be rewritten (2).

> Suppose that Bitcoin nodes just accepted the block with the largest PoW every 10 minutes.

The very problem is: look it not from the perspective of the whole system. Look it from the perspective of **my** Bitcoin-qt client bootstrapping right now from void.

How can my client be sure that **nobody is retaining blocks**? How can my client be sure about the network size judging from the input of other malicious peers?

Satoshi expected the network to grow and the computational power along with it. With more mining nodes, a larger number of blocks would hit the difficulty treshold in less than 10 minutes.

From the perspective of a **lonely** node, which is the very concept of peer-to-peer networks, the target is not to identify the block with the largest difficulty, which would be difficult if peers try to hide information, but look for **the longest chain**

The longest-chain principle does not prevent Alice completely from rewriting a transaction. It makes it so expensive that, at least for grocery purchases, it's worth following the rules than cheating.

And is the very reason why peers require 3 or more confirmations to consider a transaction *final*.

(1) Bitcoin was designed in order both to buy grocery and real estate. Of course, it's not that loss a double spend at the grocery

(2) Rewriting a transaction, in the scope of a blockchain, means that if transaction occurred at block `100`, replacing every block from `100` to `current` with `100`1 to `current`1

> **Comments:**
> **username_0**: *How can my client be sure that nobody is retaining blocks?* -- You can't be sure of that in Bitcoin either. There could very well be fork with more work (a "longest chain") that you're not aware of. Bitcoin nodes just assume they've met enough collaborating peers to get that data. My proposed system does the same. The only difference is that, instead of a target difficulty, the node just picks the block with largest work. For the PoV of a lone node, it just collects blocks and computes the longest chain of the blocks it does see. It doesn't need a central party in any form to reach consensus.  

---

