Does this make sense? (Idea to speed up block generation)

[eoJ]

Instead of making this post overcomplicated, by getting hashes involved, let's say block generation is based on succesfully guessing a number, from 1-100.

You have a room of 10 people, they're allowed to make one guess every 5 seconds. You want to guess the number as fast as possible.

Do you get them all to just blurt out random numbers every 5 seconds (creating a ton of overlap) or do you assign each of them a range, one person is 1-10, another is 11-20, another is 21-30, etc. The answer seems obvious.

I can't say I have a huge understanding of the block hashing algorithm, so if this is a stupid idea/would never work, feel free to say, a long answer isn't required.

However, could the same principle not be applied to hashes? Each gets assigned a certain range, and from there it's random. People can set their own assigned range if they so desire. As a result of the decreased overlap, blocks are generated faster, and less time is wasted trying hashes that've already been tried.

Again, sorry if this is a stupid idea. Thoughts?

[1715155555]

1715155555

[john11johng]

Well block generation is set at a target for every 10 minutes. 


Currently this is above target. Why would it need to be quicker?

[eoJ]

Well block generation is set at a target for every 10 minutes. 


Currently this is above target. Why would it need to be quicker?

Because half an hour is a long time for a shop owner to wait, to give one example.

[pontiacg5]

Hashing doesn't work that way. You have no idea what a number's resulting hash will be until you do the work.

The only thing you can change is the noonce. It is possible to give a group of people a set of numbers to try as a noonce. They call these mining pools.

Trying to get the block solve time below what is is coded for in protocol, permanently, is a loosing battle.

[eoJ]

Fair enough, I knew there was a flaw in that plan

[lnternet]

If we were guessing numbers 0-10, double guessing would indeed make it less efficient by a lot. But we are number guessing 0 - 2^265, so avoiding double guessing will be more than negligible if you look at the efficency.

[Racer8]

The only thing you can change is the noonce. It is possible to give a group of people a set of numbers to try as a noonce. They call these mining pools.

As a matter of interest how is the noonce chosen by mining programs when you are solo mining?

[DeathAndTaxes]

The only thing you can change is the noonce. It is possible to give a group of people a set of numbers to try as a noonce. They call these mining pools.

As a matter of interest how is the noonce chosen by mining programs when you are solo mining?

Same way you do when pool mining try them all?

Take a block header, append 0x00000000 (zero nonce) hash it, is it good?  nope.  Increment it by one.  Try again.  Keep going until you find a good hash or you reach the highest nonce 2^32 -1. 

When you reach the highest nonce, modify something in the blockheader (timestamp, txs, field in coinbase tx, etc) and start all over again.  Continue until you either die or find a block.  If you find a block publish it to the network and start all over.

[DeathAndTaxes]

If we were guessing numbers 0-10, double guessing would indeed make it less efficient by a lot. But we are number guessing 0 - 2^265, so avoiding double guessing will be more than negligible if you look at the efficency.

There is no double guessing.

We aren't guessing just a nonce.

It is:

IF SHA-256(SHA-256(block header))  < target THEN you solved a block.

The block header contains more than just the nonce. 
https://en.bitcoin.it/wiki/Block_hashing_algorithm

One thing it contains is the merkle tree which is a unique hash representing the txs in the block.   One of those transactions is the coinbase or "free coins" transaction.  Every pool or solo miner is going to have a unique reward tx thus the merkle tree is unique and thus the block header is unique.

The only way there is duplicate work is if a poorly designed pool sends the same work to two different miners.  Of course a pool that does that is going to earn <100% of their reward and if they are really bad (like duplicate all work) it would be 50%.  The bad pool fails and miners go to better run pools.

[DeathAndTaxes]

Well block generation is set at a target for every 10 minutes. 


Currently this is above target. Why would it need to be quicker?

Because half an hour is a long time for a shop owner to wait, to give one example.

There is no overlap, all miners are working on unique work. 
The 10 minute target is a design decision.  It could be 100 minute or 1 minute.  No need to change mining to target a different interval. 

[Racer8]

The only thing you can change is the noonce. It is possible to give a group of people a set of numbers to try as a noonce. They call these mining pools.

As a matter of interest how is the noonce chosen by mining programs when you are solo mining?

Same way you do when pool mining try them all?

Take a block header, append 0x00000000 (zero nonce) hash it, is it good?  nope.  Increment it by one.  Try again.  Keep going until you find a good hash or you reach the highest nonce 2^32 -1. 

When you reach the highest nonce, modify something in the blockheader (timestamp, txs, field in coinbase tx, etc) and start all over again.  Continue until you either die or find a block.  If you find a block publish it to the network and start all over.

Thanks for the explanation.  Is the current block header the starting point - i.e. will all solo miners be starting with the same value?

[DeathAndTaxes]

Thanks for the explanation.  Is the current block header the starting point - i.e. will all solo miners be starting with the same value?

No.  The nonce range is only 2^32 or ~4 billion values (in hindsight mining algorithm would be a lot cleaner if Satoshi had made it 64 bit nonce but no changing that now).  This means a 400 GH/s rig for example will go through the entire nonce range on a block header in 1/100th of a second. 

There is more info two posts up but all miners are working on UNIQUE block headers and changing them to different unique block headers.  No two miners (outside of badly coded pool) are ever working on the same "work" (blockheader).