user32710: 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.

user1042: 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 1001 to current1

user105152: Two potential problems with this idea, somewhat related.

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.

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.

user124790: 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.

user5406: 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.

32710: <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>
 1042: <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>
 105152: <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>
 124790: <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>
 5406: <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>
