Pages:
Author

Topic: Block generation technical specifics (Read 1745 times)

sr. member
Activity: 277
Merit: 250
September 10, 2014, 10:53:56 AM
#31
Can you guys tell me if this is correct? If there's even a small error please point it out, this has to be 100% accurate. Note that this text is owned by me and do not use it anywhere else for neither commercial nor personal use without asking me for permission first. Thanks.

What a miner is doing when it's running is generating millions of hashes every second. A hash looks something like 00000000000000000b8cd4a8a7752ff8785f66232359273f619f6a6cb28d4644.
A hash is always 64 characters long. Each block has a 'target' hash, which looks similar to the string of characters above. When the hash that your miner generates has a lower value than the target hash, you win the block. An example with smaller numbers would be a target hash of 0007b5 (note that this isn't an actual hash for bitcoin as it isn't 64 characters long, this is just an example). If your miner generates the hash 0007a5, you win the block. However, if it generates the hash 0007c5, you don't win the block. The order of the 'value' of the characters from lowest to highest value are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f.
As the difficulty increases, the 'value' of the target hash becomes lower, as more zeroes are added on to the beginning. This makes it harder for your miner's hash to have a lesser value than the target hash, so it gets harder to win the block. Notice how the example target hash above had 17 zeroes at the beginning, while the target hash of https://blockchain.info/block-index/14849">the first ever mined block had only 10 zeroes at the beginning.
sr. member
Activity: 277
Merit: 250
September 09, 2014, 06:27:50 PM
#30
Oh, I thought the only characters that mattered were the beginning zeroes. I think I get it now. Just making sure, numbers are 'less than' letters right? ie if '000aaa' is the target, '000aa9' would work. If '000999' were the target, '00099a' wouldn't work. Right?

Hashes actually use Hexadecimal no. system, which consists of 16 base values 0-f instead of 0-9 of decimal no. system. The base values are as follows => 0 1 2 3 4 5 6 7 8 9 a b c d e f
Ah, ok, thanks Smiley
sr. member
Activity: 277
Merit: 250
September 09, 2014, 06:24:50 PM
#29
I was off trying to get the link for the orphaned blocks for you.  The link is:

https://blockchain.info/orphaned-blocks

But it appears to be broken right now.  You can probably see them through another block explorer - there are many others.

I have to go but someone else can explain the conflict resolution OR it may be time for you to just bite the bullet and read Satoshi's paper.  From what you have written and understood so far you can read it and understand it.  It is not that long and it is not that difficult.  Give it a try.
I was actually planning on reading that, I printed it out last night Smiley

Now that I'm moving onto moar technical aspects of bitcoin I need to read it. Thanks a lot bud.
legendary
Activity: 2394
Merit: 1216
The revolution will be digital
September 09, 2014, 06:15:56 PM
#28
I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.
 

U actually omit the part of explaining what 'Hash the block' means, which is part of jackjack's explanation.

By the way, is there any known function to adjust the nonce to get a lower hash ?
No, that's the point of hashing functions: the output can't be predicted.


Quote
I get that you're trying to make it simpler, but I really wanna know the way it's done correctly. Even if it's confusing.
Well, the process is literally what I described. Just with bigger numbers.
Let's say the current target is 000...0004c7b (with enough zeroes replacing the "..." to have 64 characters)
Then the accepted hashes for the next block will be all the hashes inferior to this target.
ie 0...004c7a, 0...004c79, 0...004c78, etc, 0...004c70, 0...004c6f, etc, 0...000000.
Oh, I thought the only characters that mattered were the beginning zeroes. I think I get it now. Just making sure, numbers are 'less than' letters right? ie if '000aaa' is the target, '000aa9' would work. If '000999' were the target, '00099a' wouldn't work. Right?

Hashes actually use Hexadecimal no. system, which consists of 16 base values 0-f instead of 0-9 of decimal no. system. The base values are as follows => 0 1 2 3 4 5 6 7 8 9 a b c d e f
legendary
Activity: 2646
Merit: 1138
All paid signature campaigns should be banned.
September 09, 2014, 06:15:48 PM
#27
I was off trying to get the link for the orphaned blocks for you.  The link is:

https://blockchain.info/orphaned-blocks

But it appears to be broken right now.  You can probably see them through another block explorer - there are many others.

I have to go but someone else can explain the conflict resolution OR it may be time for you to just bite the bullet and read Satoshi's paper.  From what you have written and understood so far you can read it and understand it.  It is not that long and it is not that difficult.  Give it a try.
sr. member
Activity: 277
Merit: 250
September 09, 2014, 06:11:58 PM
#26
In fact blockchain.info will show both of the blocks until the conflict gets resolved, even then you can still see the orphaned blocks.  You can go check out all the orphaned blocks right now on their web site.  They also keep statistics on how often blocks get orphaned:

https://blockchain.info/charts/n-orphaned-blocks?timespan=180days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

How this conflict gets resolved ? Who has the lower hash among the 2 or more hashes below target becomes the ultimate winner to get 25 BTC + Miner fee ? If not, then what is the mechanism to break the tie ?
From what I understand, it gets resolved by the next block that's mined – there's two hashes to be solved (one for each conflict block), and depending on which one gets solved, that's the block that wins. Can someone confirm this?

Nevermind^^, I think it's just based on which block the nodes agree upon. I'm not sure how the nodes decide which block, however. Can someone confirm this? Tongue
sr. member
Activity: 277
Merit: 250
September 09, 2014, 06:10:25 PM
#25
In fact blockchain.info will show both of the blocks until the conflict gets resolved, even then you can still see the orphaned blocks.  You can go check out all the orphaned blocks right now on their web site.  They also keep statistics on how often blocks get orphaned.
Awesome, I get it now, thanks Smiley

Would the conflict blocks count as two confirmations? Logically it seems like it would only count as one.

Wait, as I was typing this I thought of something else Tongue I don't understand how they could be solved at the same time. As soon as the block is solved by one miner, it's broadcasted within a fraction of a second of being solved (right?). As soon as it's broadcasted, all miners receive the message that it was solved and start solving a new hash. This should all happen in less than a second I think. What are the odds that two miners solve the same block in less than a second?

I understand that you said it's not like a clock, so the first one to solve it doesn't necessarily win – but as soon as all of the miners realize that the block was solved, why would they continue on the same block?
legendary
Activity: 2394
Merit: 1216
The revolution will be digital
September 09, 2014, 06:08:23 PM
#24
In fact blockchain.info will show both of the blocks until the conflict gets resolved, even then you can still see the orphaned blocks.  You can go check out all the orphaned blocks right now on their web site.  They also keep statistics on how often blocks get orphaned:

https://blockchain.info/charts/n-orphaned-blocks?timespan=180days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

How this conflict gets resolved ? Who has the lower hash among the 2 or more hashes below target becomes the ultimate winner to get 25 BTC + Miner fee ? If not, then what is the mechanism to break the tie ?
legendary
Activity: 2646
Merit: 1138
All paid signature campaigns should be banned.
September 09, 2014, 06:04:18 PM
#23
In fact blockchain.info will show both of the blocks until the conflict gets resolved, even then you can still see the orphaned blocks.  You can go check out all the orphaned blocks right now on their web site.  They also keep statistics on how often blocks get orphaned:

https://blockchain.info/charts/n-orphaned-blocks?timespan=180days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
sr. member
Activity: 277
Merit: 250
September 09, 2014, 06:01:55 PM
#22
How can there be a tie if the first one to get a hash less than the difficulty wins?
Bitcoin does not use a world wide clock to tell who wins.  Two miners can get hashes that are both less than the target at more or less the same time.  They both can claim the 25 BTC at more or less the same time.  If one miner is on one side of the planet and the other one is on the other side of the planet then parts of the network will agree with miner one and parts of the network will agree with miner two.  So the conflict gets resolved but not by using a clock - because that would not work.

Once the conflict is resolved by all the nodes on the system one of the two blocks get accepted by everyone and the other one is thrown out.  The miner that gets accepted by everyone gets the block reward and fees.  The other miner gets the shaft, what we call an orphaned block.  This happens all the time.
I think I understand what you're saying but one question:

On blockchain.info it shows all of the discovered blocks. If one block is solved by two miners, will the block show up twice? Or will blockchain.info wait until the next block is solved so it sees which one was accepted?
sr. member
Activity: 277
Merit: 250
September 09, 2014, 05:59:08 PM
#21
I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.
 

U actually omit the part of explaining what 'Hash the block' means, which is part of jackjack's explanation.

By the way, is there any known function to adjust the nonce to get a lower hash ?
No, that's the point of hashing functions: the output can't be predicted.


Quote
I get that you're trying to make it simpler, but I really wanna know the way it's done correctly. Even if it's confusing.
Well, the process is literally what I described. Just with bigger numbers.
Let's say the current target is 000...0004c7b (with enough zeroes replacing the "..." to have 64 characters)
Then the accepted hashes for the next block will be all the hashes inferior to this target.
ie 0...004c7a, 0...004c79, 0...004c78, etc, 0...004c70, 0...004c6f, etc, 0...000000.
Oh, I thought the only characters that mattered were the beginning zeroes. I think I get it now. Just making sure, numbers are 'less than' letters right? ie if '000aaa' is the target, '000aa9' would work. If '000999' were the target, '00099a' wouldn't work. Right?
legendary
Activity: 2394
Merit: 1216
The revolution will be digital
September 09, 2014, 05:58:42 PM
#20
How can there be a tie if the first one to get a hash less than the difficulty wins?
Bitcoin does not use a world wide clock to tell who wins.  Two miners can get hashes that are both less than the target at more or less the same time.  The both can claim the 25 BTC at more or less the same time.  If one miner is on one side of the planet and the other one is on the other side of the planet then parts of the network will agree with miner one and parts of the network will agree with miner two.  So the conflict gets resolved but not by using a clock - because that would not work.

U mean who has the lower hash among the 2 or more hashes below target becomes the ultimate winner ?
legendary
Activity: 2646
Merit: 1138
All paid signature campaigns should be banned.
September 09, 2014, 05:56:23 PM
#19
How can there be a tie if the first one to get a hash less than the difficulty wins?
Bitcoin does not use a world wide clock to tell who wins.  Two miners can get hashes that are both less than the target at more or less the same time.  They both can claim the 25 BTC at more or less the same time.  If one miner is on one side of the planet and the other one is on the other side of the planet then parts of the network will agree with miner one and parts of the network will agree with miner two.  So the conflict gets resolved but not by using a clock - because that would not work.

Once the conflict is resolved by all the nodes on the system one of the two blocks get accepted by everyone and the other one is thrown out.  The miner that gets accepted by everyone gets the block reward and fees.  The other miner gets the shaft, what we call an orphaned block.  This happens all the time.
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
September 09, 2014, 05:55:55 PM
#18
I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.
 

U actually omit the part of explaining what 'Hash the block' means, which is part of jackjack's explanation.

By the way, is there any known function to adjust the nonce to get a lower hash ?
No, that's the point of hashing functions: the output can't be predicted.


Quote
I get that you're trying to make it simpler, but I really wanna know the way it's done correctly. Even if it's confusing.
Well, the process is literally what I described. Just with bigger numbers.
Let's say the current target is 000...0004c7b (with enough zeroes replacing the "..." to have 64 characters)
Then the accepted hashes for the next block will be all the hashes inferior to this target.
ie 0...004c7a, 0...004c79, 0...004c78, etc, 0...004c70, 0...004c6f, etc, 0...000000.
legendary
Activity: 2646
Merit: 1138
All paid signature campaigns should be banned.
September 09, 2014, 05:51:20 PM
#17
By the way, is there any known function to adjust the nonce to get a lower hash ?
No.  If there was then the hashing function is broken, Bitcoin is broken and every other system that uses the hashing function is broken.
sr. member
Activity: 277
Merit: 250
September 09, 2014, 05:47:49 PM
#16
Thanks for the help everyone.

I think I understand it a bit more, but still have some questions:

Did you look at this page?
It explains the process quite nicely
https://en.bitcoin.it/wiki/Block_hashing_algorithm

What do you mean "the same hash as the one in the block?"

I believe he is asking if his miner is looking for the "answer" that is calculated when the block is established.

So imagine you go up to a really hard math problem you've never seen; It has an answer, you just don't know what it is. He is asking if that's how Bitcoin works.

The page you've posted is the best answer to this question.
I see.
Actually we're not looking for a specific hash, we're looking for any hash that starts with enough zeroes.
So yeah, the best answer is the page I posted. See also my previous post and the question it was replying to.
I noticed the line in the article about zeroes: "Note that the actual hash, which is a 256-bit number, has lots of leading zero bits. When stored or printed as a big-endian hexadecimal constant, but it has leading zero bytes and if stored or printed as little-endian, these are the trailing zero bytes. E.g. if interpretation as a string -- lowest (or start of) string address keeps lowest significant byte, thus little-endian. The output of blockexplorer displays the hash values as big-endians numbers as notation for numbers is usual -- leading digits are the most significant digits read from left to right."

Not gonna lie, I hardly understand anything in that paragraph.

So, if I'm understanding you right, when the hash has you generate has enough zeroes, you discover that block? Is the amount of zeroes needed defined by the difficulty? And if all hashes start with zeroes, what makes it so hard for the hash to have the right number of zeroes?
Forget about that paragraph it's just deep thoughts about numbers representations inside processors.

Yes.
Yes.
The difficulty is that the result of the hashing function is random. For example let's imagine I create a hashing function that takes some data in and returns a number between 00000 and 99999. Then if the target is 09999 it will be easier to find a matching block than if the target is 00009.
09999 would make 1 hash out of 10 valid, whereas with 00009, only 1 hash out of 10000 would be valid.


I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.

Since two miners can get two different hashes which are both less than the target you can have "ties" so there is a mechanism to break "ties"

The timestamps are not used as timestamps since they are not reliable and can be faked.

If there is a tie between two miners then the hashes produce by the two (or more) miners in the tie will always be different results but they will all need to be less than the target to be "winners"
 

Indeed it's not correct, but I think it's easier too understand when you're not familiar with the hexadecimal notation.
I get that you're trying to make it simpler, but I really wanna know the way it's done correctly. Even if it's confusing.
legendary
Activity: 2394
Merit: 1216
The revolution will be digital
September 09, 2014, 05:47:24 PM
#15
I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.
 

U actually omit the part of explaining what 'Hash the block' means, which is part of jackjack's explanation.

By the way, is there any known function to adjust the nonce to get a lower hash ?
sr. member
Activity: 277
Merit: 250
September 09, 2014, 05:42:52 PM
#14
I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.

Since two miners can get two different hashes which are both less than the target you can have "ties" so there is a mechanism to break "ties"

The timestamps are not used as timestamps since they are not reliable and can be faked.

If there is a tie between two miners then the hashes produce by the two (or more) miners in the tie will always be different results but they will all need to be less than the target to be "winners"
 
How can there be a tie if the first one to get a hash less than the difficulty wins?
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
September 09, 2014, 05:37:08 PM
#13
Thanks for the help everyone.

I think I understand it a bit more, but still have some questions:

Did you look at this page?
It explains the process quite nicely
https://en.bitcoin.it/wiki/Block_hashing_algorithm

What do you mean "the same hash as the one in the block?"

I believe he is asking if his miner is looking for the "answer" that is calculated when the block is established.

So imagine you go up to a really hard math problem you've never seen; It has an answer, you just don't know what it is. He is asking if that's how Bitcoin works.

The page you've posted is the best answer to this question.
I see.
Actually we're not looking for a specific hash, we're looking for any hash that starts with enough zeroes.
So yeah, the best answer is the page I posted. See also my previous post and the question it was replying to.
I noticed the line in the article about zeroes: "Note that the actual hash, which is a 256-bit number, has lots of leading zero bits. When stored or printed as a big-endian hexadecimal constant, but it has leading zero bytes and if stored or printed as little-endian, these are the trailing zero bytes. E.g. if interpretation as a string -- lowest (or start of) string address keeps lowest significant byte, thus little-endian. The output of blockexplorer displays the hash values as big-endians numbers as notation for numbers is usual -- leading digits are the most significant digits read from left to right."

Not gonna lie, I hardly understand anything in that paragraph.

So, if I'm understanding you right, when the hash has you generate has enough zeroes, you discover that block? Is the amount of zeroes needed defined by the difficulty? And if all hashes start with zeroes, what makes it so hard for the hash to have the right number of zeroes?
Forget about that paragraph it's just deep thoughts about numbers representations inside processors.

Yes.
Yes.
The difficulty is that the result of the hashing function is random. For example let's imagine I create a hashing function that takes some data in and returns a number between 00000 and 99999. Then if the target is 09999 it will be easier to find a matching block than if the target is 00009.
09999 would make 1 hash out of 10 valid, whereas with 00009, only 1 hash out of 10000 would be valid.


I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.

Since two miners can get two different hashes which are both less than the target you can have "ties" so there is a mechanism to break "ties"

The timestamps are not used as timestamps since they are not reliable and can be faked.

If there is a tie between two miners then the hashes produce by the two (or more) miners in the tie will always be different results but they will all need to be less than the target to be "winners"
 

Indeed it's not correct, but I think it's easier too understand when you're not familiar with the hexadecimal notation.
legendary
Activity: 2646
Merit: 1138
All paid signature campaigns should be banned.
September 09, 2014, 05:34:26 PM
#12
I think number of zeros is confusing and is actually not even correct.

Look upon the hash as a big long number.  The target is actually another number.

Mining is this, in a nutshell:

1) Hash the block
2) Is the hash of the block less than the current target (which is just a number set by the protocol about every two weeks)
3) If yes you win, broadcast your result collect your 25 BTC
4) If no then modify the block so you will get a different result when you calculate the hash, go to step 1)

Do steps 1-4 as fast as you possibly can.

Since two miners can get two different hashes which are both less than the target you can have "ties" so there is a mechanism to break "ties"

The timestamps are not used as timestamps since they are not reliable and can be faked.

If there is a tie between two miners then the hashes produce by the two (or more) miners in the tie will always be different results but they will all need to be less than the target to be "winners"
 
Pages:
Jump to: