10 minutes blockchain vs difficulty level

[ranochigo]

3). As the way the bitcoin core code is written now, the level of difficulty is inversely correlated to the hash rate, to keep the average of blockchain interval  @ ~ approximately ~ 10 minutes- thus 12.5 bitcoins is released every 10 minutes.

Isn't it directly correlated? If the hashrate increases, the difficulty increases.

faster validation of the block, e.g. 1 minute instead of 10 minutes

Blocks are actually validated fairly quickly, within seconds. If you mean for blocks to be generated quickly, its discussed to death.

 > but don't release the new block until the 10 minutes is up...in the end we would be able to completely avoid the hash rate race, thus saving energy,  avoid mining push for fancy equipment and centralization of mining pool/ conglomerates ...?

Its actually hard for nodes or miners to keep track of the block interval. Blocks have a timestamp but they might not be accurate. The protocol actually lets them deviate from the most accurate time.

There's this flaw that I feel would be a problem. If you were to release the block only at blocks of 10 minutes and the difficulty is low, there is a potential for many blocks generated at the same block height. Only one of them will get accepted and the rest would be orphaned. Isn't that wasting hashpower instead?

[1715181379]

1715181379

[1715181379]

1715181379

[Anarc Senior]

3). As the way the bitcoin core code is written now, the level of difficulty is inversely correlated to the hash rate, to keep the average of blockchain interval  @ ~ approximately ~ 10 minutes- thus 12.5 bitcoins is released every 10 minutes.

Isn't it directly correlated? If the hashrate increases, the difficulty increases.

Sorry, you are correct hashrate increases > the difficulty increases.

faster validation of the block, e.g. 1 minute instead of 10 minutes

Blocks are actually validated fairly quickly, within seconds. If you mean for blocks to be generated quickly, its discussed to death.

Yes you are correct I meant block to be generated quickly- what was the outcome of the "discussion to death" - what was the conclusion ?

 > but don't release the new block until the 10 minutes is up...in the end we would be able to completely avoid the hash rate race, thus saving energy,  avoid mining push for fancy equipment and centralization of mining pool/ conglomerates ...?

Its actually hard for nodes or miners to keep track of the block interval. Blocks have a timestamp but they might not be accurate. The protocol actually lets them deviate from the most accurate time.

There's this flaw that I feel would be a problem. If you were to release the block only at blocks of 10 minutes and the difficulty is low, there is a potential for many blocks generated at the same block height. Only one of them will get accepted and the rest would be orphaned. Isn't that wasting hashpower instead?

What about releasing the block quickly as soon as it's confirm to avoid too many orphaned blocks,  but don't start the new block until the 10 minutes interval is up ?

Perhaps now with the Lightning Network layer, it could also be used to track the 10 minutes interval to start the next block and track the release of 12.5 bitcoins at every 10 minutes ?

[ranochigo]

Yes you are correct I meant block to be generated quickly- what was the outcome of the "discussion to death" - what was the conclusion ?

The discussion was geared toward the scalability of Bitcoin. There are obviously pros and cons for it, but none of that was specific to the intention of helping small miners.

What about releasing the block quickly as soon as it's confirm to avoid too many orphaned blocks,  but don't start the new block until the 10 minutes interval is up ?

In a perfect world, sure. But honestly, everyone would mine it immediately after the last block. The difficulty would have to be sufficiently high to have the chance of two conflicting blocks lowered.

I would say it would likely result in blocks going way above the 10mins interval.

Perhaps now with the Lightning Network layer, it could also be used to track the 10 minutes interval to start the next block and track the release of 12.5 bitcoins at every 10 minutes ?

I'm not exactly super familiar with lightning network so I'll leave it to others. I don't think lightning network would be suitable to distribute the block rewards though.

[haltingprobability]

All we are saying is to save wasteful electricity, hash rate push for more powerful equipment - why don't we just not increase the level of difficulty ( keep the same level of difficulty)  > faster validation of the block, e.g. 1 minute instead of 10 minutes  > but don't release the new block until the 10 minutes is up...in the end we would be able to completely avoid the hash rate race, thus saving energy,  avoid mining push for fancy equipment and centralization of mining pool/ conglomerates ...?

Since we've locked the difficulty, in this example, once we've gotten down to 1 minute between blocks, why stop there? Why not let it go down to 1 second or 1 millisecond or 1 nanosecond?

You can see here that the hashrate has increased at a geometric rate over Bitcoin's lifetime. The hashrate crossed the 1MTh/s threshold in Jan 2016 and now stands around 12MTh/s. Suppose blocks had been mining at a rate of 1 every minute in Jan 2016, they would now be mining at a rate of one every 5 seconds. How is a global peer-to-peer network supposed to stay in a single, well-defined state with an update time of just 5 seconds? Even for a trivial state, like a binary state, this would be a challenging engineering problem. But for something as complex as the blockchain, it's not possible, it's not even close to possible. At the current growth rate, within another year, that 5 seconds would be down to 416 milliseconds, so your engineering problem is getting worse, day by day.

That's why the difficulty is adjustable. The 1MB block size and 10m average mining time target are as good as any other because we can compress transactions using off-chain systems like payment channels and Lightning Networks. The main chain doesn't need to "go fast" because it can act as a final settlement layer for multiple 2nd-layer, 3rd-layer, etc. services built on top.

[Anarc Senior]

All we are saying is to save wasteful electricity, hash rate push for more powerful equipment - why don't we just not increase the level of difficulty ( keep the same level of difficulty)  > faster validation of the block, e.g. 1 minute instead of 10 minutes  > but don't release the new block until the 10 minutes is up...in the end we would be able to completely avoid the hash rate race, thus saving energy,  avoid mining push for fancy equipment and centralization of mining pool/ conglomerates ...?

Since we've locked the difficulty, in this example, once we've gotten down to 1 minute between blocks, why stop there? Why not let it go down to 1 second or 1 millisecond or 1 nanosecond?

You can see here that the hashrate has increased at a geometric rate over Bitcoin's lifetime. The hashrate crossed the 1MTh/s threshold in Jan 2016 and now stands around 12MTh/s. Suppose blocks had been mining at a rate of 1 every minute in Jan 2016, they would now be mining at a rate of one every 5 seconds. How is a global peer-to-peer network supposed to stay in a single, well-defined state with an update time of just 5 seconds? Even for a trivial state, like a binary state, this would be a challenging engineering problem. But for something as complex as the blockchain, it's not possible, it's not even close to possible. At the current growth rate, within another year, that 5 seconds would be down to 416 milliseconds, so your engineering problem is getting worse, day by day.

That's why the difficulty is adjustable. The 1MB block size and 10m average mining time target are as good as any other because we can compress transactions using off-chain systems like payment channels and Lightning Networks. The main chain doesn't need to "go fast" because it can act as a final settlement layer for multiple 2nd-layer, 3rd-layer, etc. services built on top.

Ok so your point is well taken - but our goal here is to save energy and save time:  

1). Assuming that we all trust your assessment that 10 minutes is an optimal interval between creating new block.  As someone has mentioned here before, it wouldn't be a bad idea for us to plot out the chart and analyze to see what the best blockchain interval should be .?  I'm still leaning how to use the bitcoin core full node, once I'm getting familiar of my way around, I could definitely doing some data analysis...perhaps, 5 or 3 minutes could be more sufficient ?..

2). As I indicated before, just because we could hash at 1 second it doesn't mean we have to confirm the block right away..? What about if we create a build-in a time delay on the off chain/ second layer (e.g. the Lightning Network, which acting as a "trafiffic cops") , let say if it's less than 5 minutes then put in a counter to count up to a fixed interval..?  I also have heard that the bitcoin core code doesn't like to use loops for the obvious reason...Look, I'm not a software developer, but I'm an automation engineer, I believe there are options that we all need to explore before we quickly shut all the doors and declare that it's impossible to address the problem...

As more technical people joining this community, we will continue to hear voices raise regarding how wasteful the hashrate and the difficulty levels are being used on bitcoin blockchain...

[ranochigo]

Ok so your point is well taken - but our goal here is to save energy and save time:  

1). Assuming that we all trust your assessment that 10 minutes is an optimal interval between creating new block.  As someone has mentioned here before, it wouldn't be a bad idea for us to plot out the chart and analyze to see what the best blockchain interval should be .?  I'm still leaning how to use the bitcoin core full node, once I'm getting familiar of my way around, I could definitely doing some data analysis...perhaps, 5 or 3 minutes could be more sufficient ?..

The only reason why anyone would do this is to scale Bitcoin. If you do that, the only thing you would do is to increase the blockchain growth and increasingly discourage people from using full node, leading to more centralisation. Miners would still continue to mine the same as before.

You can try but you need all of the users and miners to agree with you.

2). As I indicated before, just because we could hash at 1 second it doesn't mean we have to confirm the block right away..? What about if we create a build-in a time delay on the second layer (e.g. the Lightning Network, which acting as a "trafiffic cops") , let say if it's less than 5 minutes then put in a counter to count up to a fixed interval..?  I also have heard that the bitcoin core code doesn't like to use loops for the obvious reason...Look, I'm not a software developer, but I'm an automation engineer, I believe there are options that we all need to explore before we quickly shut all the doors and declare that it's impossible to address the problem...

If so, then the blocks are going to pile up higher and higher. After an hour or so, you would probably have a few thousand blocks and of those, most of them are empty. There would just be many forks of it and that's definitely not what we want. It doesn't discourage miners at any sense and would simply increase the time needed for a transaction to be included in a block.

Energy consumption won't be the problem that Bitcoin has. There is more energy being used for more useless stuff than for securing a currency with such a high transaction volume. It's all about making compromise.

[haltingprobability]

1). Assuming that we all trust your assessment that 10 minutes is an optimal interval between creating new block.  

No one said it's optimal. Without any other empirical data, however, it's good enough. It gets the job done. The interval could surely be lower but no one knows how much. Nine minutes? Eight minutes? We don't know. Bitcoin is in alpha development and security has to come first. The Bitcoin network, today, moves more than two billion dollars per hour (see here). We can be quite sure that 10 minutes is enough because propagation delay for unobstructed light around the planet is about 7-8 seconds. That means that there is enough time for almost 100 network-wide updates before the next block is due to arrive. The probability that the network could not reach consensus in this time is virtually zero. And that's precisely where we want it to be - virtually zero.

As someone has mentioned here before, it wouldn't be a bad idea for us to plot out the chart and analyze to see what the best blockchain interval should be .?  

That will be a great PhD project in 10-20 years' time: "Minimizing Bitcoin block time based on empirical evaluation of mean network-wide time-to-consensus."

I'm still leaning how to use the bitcoin core full node, once I'm getting familiar of my way around, I could definitely doing some data analysis...perhaps, 5 or 3 minutes could be more sufficient ?..

Or perhaps 5 seconds or 3 seconds or 8 minutes or 7.5 minutes. Without data generated from reproducible experiments, it's anybody's guess.

2). As I indicated before, just because we could hash at 1 second it doesn't mean we have to confirm the block right away..? What about if we create a build-in a time delay on the off chain/ second layer (e.g. the Lightning Network, which acting as a "trafiffic cops") , let say if it's less than 5 minutes then put in a counter to count up to a fixed interval..?  I also have heard that the bitcoin core code doesn't like to use loops for the obvious reason...Look, I'm not a software developer, but I'm an automation engineer, I believe there are options that we all need to explore before we quickly shut all the doors and declare that it's impossible to address the problem...

As more technical people joining this community, we will continue to hear voices raise regarding how wasteful the hashrate and the difficulty levels are being used on bitcoin blockchain...

No doors have been shut. Bitcoin is moving more than 2 billion dollars per hour, worldwide. Making up new numbers for block generation target time out of thin air is silly. Adding gizmos and widgets to try to patch up a broken block generation target time is even sillier. As I said earlier, feel free to start an altcoin. Cryptocurrencies are one of the few truly free markets in the world. But these proposals are incompatible with Bitcoin.

[Anarc Senior]

2). As I indicated before, just because we could hash at 1 second it doesn't mean we have to confirm the block right away..? What about if we create a build-in a time delay on the off chain/ second layer (e.g. the Lightning Network, which acting as a "trafiffic cops") , let say if it's less than 5 minutes then put in a counter to count up to a fixed interval..?  I also have heard that the bitcoin core code doesn't like to use loops for the obvious reason...Look, I'm not a software developer, but I'm an automation engineer, I believe there are options that we all need to explore before we quickly shut all the doors and declare that it's impossible to address the problem...

As more technical people joining this community, we will continue to hear voices raise regarding how wasteful the hashrate and the difficulty levels are being used on bitcoin blockchain...

[/quote] No doors have been shut. Bitcoin is moving more than 2 billion dollars per hour, worldwide. Making up new numbers for block generation target time out of thin air is silly. Adding gizmos and widgets to try to patch up a broken block generation target time is even sillier. As I said earlier, feel free to start an altcoin. Cryptocurrencies are one of the few truly free markets in the world. But these proposals are incompatible with Bitcoin.
[/quote]

Once again, your point is well taken:  I agree that they're a lot at stake right now - technically, politically, the geo-political and PR, etc...i sometime feel that this is bigger than bitcoin or even blockchain technology.  I believe that what ever happens in the next several years, will potentially impact and shape the destiny of humanity...

To your point, what ever we do to the bitcoin network today would be like fixing an airplane  while flying in the air...but we also want to protect the airplane from being shot down...