Using a constant difficulty, is it possible to create the longest chain?

[Dzwaafu11]

I think the miners will be able to determine the length of a blockchain after they have completed their task, so now what I want to know is: Can the miners obtain the longest chain by maintaining the low constant difficulty?

Or will it not function until they produce a large number of blocks and then alter timestamps to maintain the constant difficulty, at which point they will be able to obtain a longer chain than the one that is already in place?

I recently came across this while reading about the technical side of bitcoin technology, and I need further explanation because it confuses me.

[1714674136]

1714674136

[1714674136]

1714674136

[1714674136]

1714674136

[EL MOHA]

No, because longest chain isn’t classified based on block numbers again or just chain length (height) as it was first classified by satoshi then. It is the most difficult or cumulative difficulty that is used to classify it.

If you look at the blocks, the difficulty varies for them to be mined, although the average time for each one is 10 minutes but the adjustment varies and since there is no constant then the longest chain is not about height no more but the cumulative difficulty.

Can the miners obtain the longest chain by maintaining the low constant difficulty?

[Synchronice]

I think the miners will be able to determine the length of a blockchain after they have completed their task, so now what I want to know is: Can the miners obtain the longest chain by maintaining the low constant difficulty?

Or will it not function until they produce a large number of blocks and then alter timestamps to maintain the constant difficulty, at which point they will be able to obtain a longer chain than the one that is already in place?

I recently came across this while reading about the technical side of bitcoin technology, and I need further explanation because it confuses me.

You can fork the bitcoin, drop the difficulty and create the longest chain right now, decrease the difficulty and mine thousand times more blocks in minutes but that doesn't mean that others will follow you or your fork will be the major fork. Your chain is the longest chain but at the same time, your chain has the tiny amount of hashes.
So, to sum up, the length of the chain doesn't matter. It was in past when the longest chain was the main chain but that was quickly fixed. Right now, the chain with the most accumulated work is the main chain.

[BlackHatCoiner]

A miner can manipulate the timestamp, and by maintaining a difficulty=1, they can mine hundreds of thousands of blocks relatively trivially, but as said by EL MOHA, block height isn't what defines the longest chain, but the total chain work which can't be faked.

[DifDrama]

Miners cannot obtain the longest chain by simply maintaining a low constant difficulty or altering timestamps. In essence, the concept of the longest chain is not determined solely by difficulty or timestamps, but by the cumulative computational effort (proof of work) expended by miners to extend the chain in a way that the rest of the network recognizes and accepts.

First,  if miners were to artificially maintain a low constant difficulty, their blocks would be mined quickly, but they would not necessarily form the longest chain.  Other miners with higher computational power would continue to mine blocks at the normal difficulty level, and their longer chain with more accumulated proof of work would eventually become the valid chain.

Second, the valid chain is the one with the most accumulated proof of work, and miners are incentivized to contribute their computational power to extend this chain honestly.  Attempting to manipulate difficulty or timestamps would likely be detected by the network and rejected, as the protocol is designed to maintain the integrity and security of the blockchain.

[odolvlobo]

Can the miners obtain the longest chain by maintaining the low constant difficulty?

1. The difficulty is determined by the protocol and not the miners. It is not possible for miners to maintain a low difficulty unless they all agree to limit their hash rates.
2. As pointed out, the "longest" chain is the one with the highest cumulative difficulty, and not the one with the most blocks. However, the two are normally equivalent except when there is a chain split.

[o_e_l_e_o]

1. The difficulty is determined by the protocol and not the miners. It is not possible for miners to maintain a low difficulty unless they all agree to limit their hash rates.

That's not entirely accurate. A majority of miners colluding to manipulate the timestamps of blocks (or a single miner with 51% of the hashrate) could also create and maintain an artificially low difficulty.

I explain how such an attack would work on a forked chain with 100% of the hashrate taking part in the attack here: https://bitcointalk.org/index.php?topic=5452676.msg62269397#msg62269397

But if we consider the scenario with say 60% of the hashrate taking part in the attack, then of the last 11 blocks we would expect 4 or 5 blocks to have a timestamp of the current time, and 6 or 7 blocks to have an altered timestamp of weeks ago. If you consider the median timestamp of those 11 blocks, it is still weeks ago and so the attack is still successful.

[Accardo]

Can the miners obtain the longest chain by maintaining the low constant difficulty?

1. The difficulty is determined by the protocol and not the miners. It is not possible for miners to maintain a low difficulty unless they all agree to limit their hash rates.

In addition to what o_e_l_e_o said, by manipulating the timestamp the difficulty adjustment algorithm will be forced to reduce the difficulty because it assumes the attacker spends longer time to mine a block. Delaying the timestamp to take longer time is more effective.

Or will it not function until they produce a large number of blocks and then alter timestamps to maintain the constant difficulty, at which point they will be able to obtain a longer chain than the one that is already in place?

With enough computing powers, if a chain with all difficult blocks solved is built and it's long enough or more than the honest chain, the nodes will reorganize and join the other chain. Which still opens room for 51% attack, this can take a huge number of miners to work on an alternate chain, and a long time too, as the bitcoin chain is quite too old to catch up with easily, if they mine from the genesis block.

On the contrary, miners don't think about this because their block rewards depends on the honest chain, and it'll take about 100 blocks ahead of the miner's block before they'll be eligible to withdraw the bitcoin, so they'll keep working on the honest chain to earn more bitcoin.

[o_e_l_e_o]

Delaying the timestamp to take longer time is more effective.

This attack is not possible without the cooperation of a majority of nodes. Block timestamps have an upper bound of two hours in the future based on network adjusted time, which is never going to be enough to result in any meaningful reduction in the difficulty. Only with a majority of nodes altering their local time to days in the future in order to accept the blocks with artificially delayed timestamps could this attack be successful.

[Dzwaafu11]

1. The difficulty is determined by the protocol and not the miners. It is not possible for miners to maintain a low difficulty unless they all agree to limit their hash rates.

That's not entirely accurate. A majority of miners colluding to manipulate the timestamps of blocks (or a single miner with 51% of the hashrate) could also create and maintain an artificially low difficulty.

I explain how such an attack would work on a forked chain with 100% of the hashrate taking part in the attack here: https://bitcointalk.org/index.php?topic=5452676.msg62269397#msg62269397

But if we consider the scenario with say 60% of the hashrate taking part in the attack, then of the last 11 blocks we would expect 4 or 5 blocks to have a timestamp of the current time, and 6 or 7 blocks to have an altered timestamp of weeks ago. If you consider the median timestamp of those 11 blocks, it is still weeks ago and so the attack is still successful.

I really appreciate O_E_L_E_O. Your explanation has been meaningful and helpful, though I enjoy how you break down everything on this thread. And I've understand what I want from your explanation.

[Accardo]

Delaying the timestamp to take longer time is more effective.

This attack is not possible without the cooperation of a majority of nodes. Block timestamps have an upper bound of two hours in the future based on network adjusted time, which is never going to be enough to result in any meaningful reduction in the difficulty. Only with a majority of nodes altering their local time to days in the future in order to accept the blocks with artificially delayed timestamps could this attack be successful.

Well, a difficulty increase by 300% for those who mined 2016 blocks before two weeks and 75% decrease for miners who spent more than two weeks may not be reasonable but has a huge difference, that can pose as an advantage. However, I'd say that the network has been well thought out against any reasonable attack, like you mentioned the majority nodes controls the network. Because a single controversial change on the consensus rules could have been a loop hole in the network and attackers would have taken advantage of it, imagine having the non-upgraded node becoming the majority against upgraded nodes that would have caused a problem to the network, but such things have been tackled with block and transaction versions. Hence, It's rare for any means of attack, that has not been thought of or being taken care of by the core developers.

[o_e_l_e_o]

Well, a difficulty increase by 300% for those who mined 2016 blocks before two weeks and 75% decrease for miners who spent more than two weeks may not be reasonable but has a huge difference, that can pose as an advantage.

Sure, that's a big difference, but how are you proposing that the network forks in two, with one subset managing to suddenly mine two weeks worth of blocks in ~3.5 days in order to cause their difficulty to increase 4x, and with the other subset taking >2 months to mine the same number of blocks?

A change which resulted in a minority of the network talking more than 2 months to mine the next 2016 blocks would simply result in that minority chain eventually being abandoned. And no change can suddenly cause the hashrate to quadruple and make the rest of the network mine four times faster.

[ranochigo]

However, I'd say that the network has been well thought out against any reasonable attack, like you mentioned the majority nodes controls the network. Because a single controversial change on the consensus rules could have been a loop hole in the network and attackers would have taken advantage of it, imagine having the non-upgraded node becoming the majority against upgraded nodes that would have caused a problem to the network, but such things have been tackled with block and transaction versions. Hence, It's rare for any means of attack, that has not been thought of or being taken care of by the core developers.

Miners influence and create forks, nodes are generally less susceptible to this sort of things. Most changes that we have so far are soft forks and there isn't any compatibility issues with the older un-upgraded nodes. The whole point about block versions is to ensure that the miners signal readiness to accept the changes to the network. This by no means prevents any sort of forks, just that if the miners have upgraded their nodes, they should have no problems with any newer rules or TX formats. They can still fork the network regardless.

The whole thing about increase in hashrate doesn't happen with Bitcoin, but it happens with altcoin due to MultiPool switching and that is only due to profitability.

[Accardo]

However, I'd say that the network has been well thought out against any reasonable attack, like you mentioned the majority nodes controls the network. Because a single controversial change on the consensus rules could have been a loop hole in the network and attackers would have taken advantage of it, imagine having the non-upgraded node becoming the majority against upgraded nodes that would have caused a problem to the network, but such things have been tackled with block and transaction versions. Hence, It's rare for any means of attack, that has not been thought of or being taken care of by the core developers.

The whole point about block versions is to ensure that the miners signal readiness to accept the changes to the network. This by no means prevents any sort of forks, just that if the miners have upgraded their nodes, they should have no problems with any newer rules or TX formats. They can still fork the network regardless.

I think you've mistaken block version number to be Miner Activated Soft Fork where a specific percentage, lets say 80%, of miners or hashrate have to signal that they're ready to use the new consensus rule, for all nodes to abide by the new rules. Block version number can be used to dictate a fork or helps to remind a user they need to upgrade their software. If the non upgraded node sees new blocks with a different block version, which they don't understand it can signal the user to upgrade, but if the non upgraded node keeps mining using the old rules and gets to block headers that has six blocks with more computing powers than the blockchain bitcoin core considers valid, it can detect this issue, using RPC command

Code:

getnetworkinfo

and

Code:

-alertnotify

this means bitcoin core can flag the blocks from non upgraded nodes as not valid and it won't be get added to the honest chain. Hence, Miner Activated Soft Fork depends solely on miners for nodes to execute the new rules while, in, block version and transaction numbers nodes work with the version number they're compatible with and ignore either the old or new version depending on the version they're wearing.

this can help us understand the block and transaction version numbers better

[ranochigo]

I think you've mistaken block version number to be Miner Activated Soft Fork where a specific percentage, lets say 80%, of miners or hashrate have to signal that they're ready to use the new consensus rule, for all nodes to abide by the new rules. Block version number can be used to dictate a fork or helps to remind a user they need to upgrade their software.

Nope, it is generally used to signal readiness. The fact that Bitcoin Core warns of the activation of unknown rules isn't always accurate; miners can use version field as extranonce for ASICBoost, though this has changed through the years.

If the non upgraded node sees new blocks with a different block version, which they don't understand it can signal the user to upgrade, but if the non upgraded node keeps mining using the old rules and gets to block headers that has six blocks with more computing powers than the blockchain bitcoin core considers valid, it can detect this issue, using RPC command

Code:

getnetworkinfo

and

Code:

-alertnotify

this means bitcoin core can flag the blocks from non upgraded nodes as not valid and it won't be get added to the honest chain. Hence, Miner Activated Soft Fork depends solely on miners for nodes to execute the new rules while, in, block version and transaction numbers nodes work with the version number they're compatible with and ignore either the old or new version depending on the version they're wearing.

That is not correct. Soft forks are activated with evaluating a range of blocks, for which N of the last M blocks are signalling a higher version bit. Bitcoin Core which are upgraded are designed to enforce the new rules with the miner's participation while maintaining backward compatibility at the same time. Upgraded clients will not reject any blocks unless the threshold is met, and for which there is still a grace period for the rest to upgrade.

It has happened before, and that was when SPV mining was prevalent. Use of versionbit did not prevent these forks: https://bitcoin.org/en/alert/2015-07-04-spv-mining. The prevention is contingent on the miners mining the blocks with the appropriate rules and the user to update their clients and hence versioning system does not explicitly prevent any sort of issues with it.

[Accardo]

Nope, it is generally used to signal readiness.

Great explanation, I went through it again, and it happened to be that the version number is like a tool used to know the amount of miners who are using the new consensus rule and to determine the status of the ungraded network and what decision to take whether to continue with both old and new rule, depending on the majority.

That is not correct. Soft forks are activated with evaluating a range of blocks, for which N of the last M blocks are signalling a higher version bit. Bitcoin Core which are upgraded are designed to enforce the new rules with the miner's participation while maintaining backward compatibility at the same time. Upgraded clients will not reject any blocks unless the threshold is met, and for which there is still a grace period for the rest to upgrade.

Regarding backward compatibility, in softfork, if the threshold is met, is the non upgraded node still eligible to be forward compatible or does the block it generates get staled? On the other flip, in my quote I wasn't writing completing about softfork, from what you said, it's not a fork at all. I was referring to hardfork while elaborating on version number. Since hard fork is non forward compatible, that is the non upgraded nodes don't follow the new rules, it poses threat to the network, does it mean bitcoin core's means of tackling those who want to perform a hard fork isn't effective?

[ranochigo]

Regarding backward compatibility, in softfork, if the threshold is met, is the non upgraded node still eligible to be forward compatible or does the block it generates get staled? On the other flip, in my quote I wasn't writing completing about softfork, from what you said, it's not a fork at all. I was referring to hardfork while elaborating on version number. Since hard fork is non forward compatible, that is the non upgraded nodes don't follow the new rules, it poses threat to the network, does it mean bitcoin core's means of tackling those who want to perform a hard fork isn't effective?

If the threshold is met and you still generate blocks that are not conforming to the new rules, then your old nodes will accept it while upgraded nodes will reject it. Fun fact, intentional hard forks are by and large only happening with splits that wants to fork a Bitcoin with different rules. We generally use soft-fork most of the time save for extraordinary circumstances (twice, 2013 chainsplit and unexploited inflation bug). Hard fork simply means that old nodes cannot accept it, regardless of what happens.

Hard fork is very complicated and lots of things can go wrong, you simply have to weight the risk and reward.