5

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.

10
  • 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
    Commented Aug 2, 2021 at 18:40
  • 2
    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
    Commented Aug 2, 2021 at 19:52
  • 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
    – Caius Jard
    Commented Aug 2, 2021 at 20:46
  • 1
    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. Commented Aug 2, 2021 at 22:20
  • 1
    @MichaelKarcher: Bitcoin looks for the chaintip with the most work: github.com/bitcoin/bitcoin/blob/…. 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
    Commented Aug 2, 2021 at 23:36

4 Answers 4

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.

18
  • 2
    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
    Commented Aug 2, 2021 at 0:38
  • 2
    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
    Commented Aug 2, 2021 at 0:40
  • 1
    @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
    Commented Aug 2, 2021 at 18:35
  • 1
    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
    Commented Aug 2, 2021 at 18:49
  • 2
    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
    Commented Aug 2, 2021 at 19:16
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.

14
  • 2
    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
    Commented Aug 2, 2021 at 18:31
  • 1
    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. Commented Aug 2, 2021 at 18:52
  • 1
    @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. Commented Aug 3, 2021 at 8:32
  • 1
    (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) Commented Aug 3, 2021 at 8:40
  • 2
    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
    Commented Aug 3, 2021 at 16:26
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.

1
  • Good points. Also appreciate this answer as it understands what I proposed.
    – MaiaVictor
    Commented Aug 16, 2021 at 22:25
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 1001 to current1

1
  • 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
    Commented Aug 2, 2021 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.