Bitcoin Forum
November 11, 2024, 11:23:32 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Block header hashing [0.15 BTC or 50 LTC Reward for best answer]  (Read 1335 times)
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
January 30, 2013, 07:12:12 PM
 #1

Hi,

I read the following links:
https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Dump_format#CBlock
https://en.bitcoin.it/wiki/Block_hashing_algorithm

And I'm still a little confused on how the block header is hashed.

First off, how are the transactions that are not part of the coinbase transaction attached to the block?  Why does hashMerkleRoot change if a new transaction enters the network?  I understand the these are being updated constantly, but are there two hash trees in any given block, one for normal transactions and one for the coinbase transaction?  How is the hash tree assembled for for the normal transactions?

When we hash the block header, are we hashing all 640 bits contained inside of it (which constantly change)?  I understand that the hashing goal is to produce a result containing a certain number of trailing zeroes based upon the difficulty, but I'm confused about the data we're hashing and how the addition of transactions changes it, and how the inclusion of our coinbase value and address changes it.  I know the first transaction for any given block is the coinbase transaction, but I'm confused as to how the addition of this into the block we're hashing changes this.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
January 30, 2013, 07:27:25 PM
Last edit: January 30, 2013, 07:40:47 PM by DeathAndTaxes
 #2

The coinbase transaction is just a transaction.  It is a "special"* transactions but it is still part of the merkle tree.  All transactions (including the coinbase) are in the merkle tree.  The merkle tree root hash changes if any element of the merkle tree changes.  You can think of the merkle tree root hash as the hash of a specific set of transactions.  Much like how a different blockheader will produce a different block hash, a different set of transactions will produce a different merkle tree root hash.

So if you add a tx to the set of transactions in the block you produce a different merkle tree = a new merkle tree root hash.
If you remove a tx to the set of transactions in the block you produce a different merkle tree = a new merkle tree root hash.
If you modify the coinbase tx you produce a different merkle tree  = a new merkle tree root hash.

The merkle tree root hash which is included in the blockheader corresponds to a specific set of transactions (including the coinbase).  By including the merkle tree root hash in the block header any solution found is only valid for that exact and specific set of transactions.  Any change of an element in the block header (difficulty, prior block hash, timestamp, merkle tree roothash, version, etc) will produce a new hash (which has the same unlikely probability of being below the difficulty target).

Since making any change to the set of transactions changes the merkle tree root hash and the merkle tree root hash is part of the blockheader, any change also changes the blockheader.  A different blockheader will produce a different block hash.  Thus you can't change anything in the block without producing a new block hash.

When you submit a block to the rest of the network other nodes will validate the block by:
a) validating all tx in the block
b) constructing the merkle tree
c) generating the markle tree root hash
d) verifying the computed merkle tree root is the same as the one in the block header.
e) hashing the block heahder and validating the hash meets the difficulty target.


On a related note this is how a miner can't "steal" the block reward for a block they solve.  The solution (hash below the difficulty target) is ONLY valid for that specific block header.  The merkle tree in the block header is only valid for that specific set of transactions.  If a miner were to replace the coinbase tx with one that sends the coins to his address it would produce a new merkle tree, thus a new merkle tree root hash, and thus a new blockhash.


* By "special" the coinbase must have the following characteristics.
1) the set of transactions in a block must have exactly one coinbase transaction (yes a block with no coinbase is invalid)
2) the coinbase transaction has no input
3) the value of the coinbase transaction must be equal to or less than (the block subsidy based on block height + sum of all the inputs of other tx in the block - sum of all outputs of other tx in the block)



tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
January 31, 2013, 05:20:54 PM
 #3

Okay, thank you.  So the transactions on the network are all propagated through the miners in a peer-to-peer fashion, with each miner including his or her coinbase transaction after the tree root?  Is there anything that stops miners from excluding transactions that they don't want going through the network when they mint blocks?

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
January 31, 2013, 05:52:56 PM
Last edit: February 01, 2013, 04:13:46 PM by DeathAndTaxes
 #4

Quote
So the transactions on the network are all propagated through the miners in a peer-to-peer fashion, with each miner including his or her coinbase transaction after the tree root?  

Correct. Although it is probably better to just think of the coinbase tx as another tx.  

When a node receives a new transaction it:
a) verifies the inputs haven't been previously spent
b) verifies the signature on the transaction is valid (signed by the private key(s) of the inputs)
c) verifies this transaction isn't already included in a block.

All (full) nodes have a complete copy of the blockchain and thus all confirmed transactions.  So it is important for a node to have an accurate record of all (known) unconfirmed transactions.  This is called the memory pool.

When a node validates a new transaction it adds it to the memory pool.
When a block is validated the block is added to the blockchain and the transactions in the block are removed from the memory pool.
When a block is orphaned the transactions in the block are added to the memory pool (many or all may be removed again if they replacing block also contains them).

This way all nodes have a set of transactions they are aware of which haven't yet been included in a block as well as all known blocks and the chain which is currently the "longest". 

Quote
Is there anything that stops miners from excluding transactions that they don't want going through the network when they mint blocks?
No.  That is intentional.  Miners are free to choose which tx then want to include in any particular block.  Miners can't force users to include a fee but they can choose to exclude low paying or non-paying transactions.  Users on the other hand aren't guaranteed inclusion in the block but can't be forced to include a fee.  The mining "economy" will meet in the middle.  Currently subsidies make the overwhelming portion of miner compensation but overtime fees will become more important.  
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
January 31, 2013, 11:09:20 PM
 #5

Okay, makes sense.  Drop an address here for LTC or BTC and I will send the reward.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
February 01, 2013, 12:01:40 AM
 #6

No reward needed.  It helps me to understand it better by explaining it to others.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!