Topic: 10 minutes blockchain vs difficulty level (Read 1856 times)

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

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

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

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.

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 ...?

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

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

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

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 ?

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?

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.

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 ...?

I feel my proposal limits the barrier to entry to having a half-decent internet connection.

As for the 10-minute block time and price, if block creation time suddenly becomes 3 minutes instead of 10 and the block reward doesn't change, then 3 times more coins than normal will be added to the network. That won't have an effect on price?

There is little difference from a network with 10 GH/s and one with 10 TH/s other than the barrier to entry is higher. Litecoin difficulty went from 130,000 to almost 1,000,000 with no difference in price or functionality this past summer.

A computer only needs to be on and connected to be selected to mine, so even something low power could mine the same as a gaming rig. My only question right now is, what is the best way for miners to advertise themselves as available to the network? Would mining be handled by the core software itself, and either vote for itself as 1 of the 10 miners or simply sign-in/sign-out of a shared database when the software is opened or closed?

The controlling factor as to what groups and sends transactions to miners is a group consensus of all online nodes. When 50 transactions are present in the mempool, they are flagged with the block number they will ultimately end up in (previous block number +1) in order of datestamp, compiled into a work unit, and broadcast to the 6+n miners that won the vote (6 required miners plus n additional miners based on minting requirements). Only those miners receive the work unit to crunch. No further transactions and no other miners are crunching until the required 6 work units are returned and match. Once that's done, then the next 50 transactions are grouped and sent to 6+n different miners. Each node randomly selects miners and votes for them. Just like a public poll, you can participate even though you don't know or trust the others that participated.

Under this new system, the block size is limited by transaction count, not MB size. And since block time depends on how fast a block can be assembled and verified and transaction load, I don't really see what gain spamming would have?

As for the 10-minute block time and price, if block creation time suddenly becomes 3 minutes instead of 10 and the block reward doesn't change, then 3 times more coins than normal will be added to the network. That won't have an effect on price?

Well, I thought you would understand but I'm talking about the coin cap.
Yeah? Aren't you talking about trying to make the difficulty constant to make it profitable for small time miners?

If you were to make the difficulty constant over a long period of time, the block frequency would become faster. With that, a 5 minute blocktime would double the total Bitcoins that would be created a day. Is that wrong?

@Anarc: I don't know what you're on, but it's rude not to share...

1). Currently, the market cap of bitcoin is not fixed at all !! In fact it's growing so fast that it blows many big corporations completely out of the water -  as of today bitcoin market cap is approximately ~ 185 billions usd !!

2). The total bitcoin being released per day is ~  1800 bitcoins -- do you understand anything about bitcoin blockchain??

Currently, the market cap is fixed so I'm not talking about that. However, with a constant difficulty, you are bound to have blocks that would be faster and faster with a constant block reward. This would result in the total market cap increasing. If you decrease the block reward proportionately, then they won't achieve your aim.

What I have devised so far is that each block is limited to 50 transactions (arbitrary number, could be higher or lower based on Bitcoin's throughput, but this figure works for Litecoin currently), and once there are 50 transactions in the mempool, they are grouped together into a work unit, and sent to a specific miner/pool for hashing.

With a fixed difficulty, crunch time is based purely on that miner's hash rate, but is ideally less than a minute. Once hashing is complete on that block/workunit, it is broadcast to the network and added to the chain. However, before being added to the chain, that block must be crunched and verified by 5 other, randomly selected miners. So, each time a work unit is created by the network, it is sent to at least 6 totally random miners (not based on hash rate, wallet balance, etc.), and the block must have 6 results that jive before being added to the blockchain. The miner selection is done by group consensus of all core nodes (each randomly votes 10 miners, top 6 are selected by popular vote). Additionally, the top 6 miners are prevented from working on the block following the one they worked on (same miner can't crunch two blocks in a row). This prevents an entity running several malicious nodes/miners from taking control of the blockchain.

The transaction fee is hard-coded at .1% of the transaction amount.

The first 10 valid hashes submitted would get an equivalent BTC amount to what each of the 6 miners received in transaction fees. So, in total, 16 miners would receive .0041667 BTC each for a total reward of .0666667 BTC for that block, and of that, .0416667 BTC would be new to the network. As market cap reaches 100% in circulation, the number of "follower" miners would be reduced, similar to how the block reward halves currently. The timeline for market growth would then be tied to transaction activity, not time.

Blocks come as fast or slow as transactions are happening, and the next group of 50 transactions can only be confirmed once the previous block has been fully verified by the 6 random miners. And if there are insufficient transactions in the mempool, block creation has a backup timer that kicks out work units 5 minutes after the previous block in case 50 transactions haven't occurred since then. This transforms the network from having a fixed throughput to being driven by network activity (the bottleneck then becomes how fast 6 miners can be selected and for those miners to crunch the transactions and make a block). So, what does this mean for miners? While this part is above my knowledge, it likely means that CPUs would become dominant again, as they are likely to sit idle most of the time, making ASICs far too power hungry to be profitable. Even GPUs may not make financial sense.

Proof-of-Work is currently intrinsically wasteful,

The way Bitcoin is coded currently, the 10-minute block is a constant that must be maintained to prevent block rewards from flooding the network and pushing the price down, as well as preventing orphaned blocks.

What I have devised so far is that each block is limited to 50 transactions (arbitrary number, could be higher or lower based on Bitcoin's throughput, but this figure works for Litecoin currently), and once there are 50 transactions in the mempool, they are grouped together into a work unit, and sent to a specific miner/pool for hashing.

With a fixed difficulty, crunch time is based purely on that miner's hash rate, but is ideally less than a minute. Once hashing is complete on that block/workunit, it is broadcast to the network and added to the chain. However, before being added to the chain, that block must be crunched and verified by 5 other, randomly selected miners. So, each time a work unit is created by the network, it is sent to at least 6 totally random miners (not based on hash rate, wallet balance, etc.), and the block must have 6 results that jive before being added to the blockchain. The miner selection is done by group consensus of all core nodes (each randomly votes 10 miners, top 6 are selected by popular vote). Additionally, the top 6 miners are prevented from working on the block following the one they worked on (same miner can't crunch two blocks in a row). This prevents an entity running several malicious nodes/miners from taking control of the blockchain.

Now, how do I account for eliminating the block reward?

Just a thought.

I've been giving a lot of thought to this lately. While I understand that Proof-of-Work is currently intrinsically wasteful, I've been trying to find a way that makes it much more energy efficient while maintaining security and functionality.

The way Bitcoin is coded currently, the 10-minute block is a constant that must be maintained to prevent block rewards from flooding the network and pushing the price down, as well as preventing orphaned blocks. However, what if difficulty was fixed, the block reward was eliminated, and block creation was driven by network transaction activity instead?

What I have devised so far is that each block is limited to 50 transactions (arbitrary number, could be higher or lower based on Bitcoin's throughput, but this figure works for Litecoin currently), and once there are 50 transactions in the mempool, they are grouped together into a work unit, and sent to a specific miner/pool for hashing. With a fixed difficulty, crunch time is based purely on that miner's hash rate, but is ideally less than a minute. Once hashing is complete on that block/workunit, it is broadcast to the network and added to the chain. However, before being added to the chain, that block must be crunched and verified by 5 other, randomly selected miners. So, each time a work unit is created by the network, it is sent to at least 6 totally random miners (not based on hash rate, wallet balance, etc.), and the block must have 6 results that jive before being added to the blockchain. The miner selection is done by group consensus of all core nodes (each randomly votes 10 miners, top 6 are selected by popular vote). Additionally, the top 6 miners are prevented from working on the block following the one they worked on (same miner can't crunch two blocks in a row). This prevents an entity running several malicious nodes/miners from taking control of the blockchain.

Now, how do I account for eliminating the block reward? That's simple. The transaction fee is hard-coded at .1% of the transaction amount. So, if someone sends 1 BTC (at the moment, valued at roughly $11,000), the transaction fee would be .001 BTC, or $11. If someone sends $5, the fee would be .5 cents. So, if a block's 50 transactions move a total of 25 BTC, the 6 miners that returned valid hashes would split the .025 BTC of transaction fees evenly (at current price of $11,000, each of the 6 miners would get $45.83 for solving that block). That accounts for miner rewards and transaction fees, but how does this add coins to the network? It would also be hard-coded that depending on the number of coins in circulation compared to the designed max coins, a certain number of additional miner hashes would be credited similar to the transaction fees. While I haven't pinned down appropriate numbers yet, say an additional 10 valid hashes are broadcast after the initial 6. The first 10 valid hashes submitted would get an equivalent BTC amount to what each of the 6 miners received in transaction fees. So, in total, 16 miners would receive .0041667 BTC each for a total reward of .0666667 BTC for that block, and of that, .0416667 BTC would be new to the network. As market cap reaches 100% in circulation, the number of "follower" miners would be reduced, similar to how the block reward halves currently. The timeline for market growth would then be tied to transaction activity, not time.

Blocks come as fast or slow as transactions are happening, and the next group of 50 transactions can only be confirmed once the previous block has been fully verified by the 6 random miners. And if there are insufficient transactions in the mempool, block creation has a backup timer that kicks out work units 5 minutes after the previous block in case 50 transactions haven't occurred since then. This transforms the network from having a fixed throughput to being driven by network activity (the bottleneck then becomes how fast 6 miners can be selected and for those miners to crunch the transactions and make a block). So, what does this mean for miners? While this part is above my knowledge, it likely means that CPUs would become dominant again, as they are likely to sit idle most of the time, making ASICs far too power hungry to be profitable. Even GPUs may not make financial sense.

Just a thought.

1). Consider the hash rate and its level of difficulty is within a black box:  from the end users standpoint, there are 12.5 bitcoins being produced every 10 minutes - no more, no less.  I cannot fatom or see any clear evidence that the higher hash rate, difficulty would directly correlate to a larger market cap of bitcoin ??

2). I don't believe for one second that more powerful and faster computers is the absolute single solution to have a secured blockchain, which would maintains its scarcity and holding its high value.  IMHO, higher hash rate is unnecessary and a completely waste of time and energy - its sole purpose is merely to give people a delusional
perceptions of some "intrinsic values" built in with the newly mined bitcoins with the higher hashrate and high level of difficulty !!  Which we all know is a complete BS !

3). More expensive equipment  and larger pool of miners do not equate to true technological innovation- let more general population in the task and soon there will be true competitition and innovation emerging...

You have jut described a text book definition of Centralization !