how do miners fill merkle_root field when mining?

[PRCman]

I am not really understand this.

[1714115747]

1714115747

[1714115747]

1714115747

[1714115747]

1714115747

[xf2_org]

Miners do not fill in merkle_root.  Miners receive a fully initialized 80-byte block header, and have permission to change a few fields in that block header (nonce, ntime) before resubmitting.

[PRCman]

Miners do not fill in merkle_root.  Miners receive a fully initialized 80-byte block header, and have permission to change a few fields in that block header (nonce, ntime) before resubmitting.

And the client send the head to miners? how do the client fill the merkle_root?

[Xenland]

Miners do not fill in merkle_root.  Miners receive a fully initialized 80-byte block header, and have permission to change a few fields in that block header (nonce, ntime) before resubmitting.

And the client send the head to miners? how do the client fill the merkle_root?

I think that last miners set the header of the merkle root although the current miner CAN set the new one IF the block is solved. As to what the header data contains i believe is the "last block" so its like a chain that it follows backwards which is used for linking up the longest chain.

The following is just a thoery but i think that the chain is used in this manner to keep people from injecting counter fit bitcoins becuase all the miners as well of the clients all check for the money/balance in the previous block transactions and blancs

[PRCman]

Miners do not fill in merkle_root.  Miners receive a fully initialized 80-byte block header, and have permission to change a few fields in that block header (nonce, ntime) before resubmitting.

And the client send the head to miners? how do the client fill the merkle_root?

I think that last miners set the header of the merkle root although the current miner CAN set the new one IF the block is solved. As to what the header data contains i believe is the "last block" so its like a chain that it follows backwards which is used for linking up the longest chain.

The following is just a thoery but i think that the chain is used in this manner to keep people from injecting counter fit bitcoins becuase all the miners as well of the clients all check for the money/balance in the previous block transactions and blancs

You mean fill it after hash? won't it change the hash value?  Is this field be exclude from hash?

[Pieter Wuille]

Miners receive the header, which contains: version number, previous block's hash, merkle root, timestamp, difficulty, nonce

This information is assembled by the bitcoin client they connect to, or the pool, and miners don't care what's in there.

The only thing they do, is try different values for nonce (knowing which bytes in the header constitute the nonce), and possibly the time stamp.

[Meni Rosenfeld]

The Bitcoin server, after deciding which transactions to include in the block, builds a Merkle tree of the transactions, probably using some standard library. The hash at the root is the merkle root.

[PRCman]

The Bitcoin server, after deciding which transactions to include in the block, builds a Merkle tree of the transactions, probably using some standard library. The hash at the root is the merkle root.

Then after a transaction, the new merkle root generated and replace the old one
since the block header has changed, how can we verify the block?

[Meni Rosenfeld]

The Bitcoin server, after deciding which transactions to include in the block, builds a Merkle tree of the transactions, probably using some standard library. The hash at the root is the merkle root.

Then after a transaction, the new merkle root generated and replace the old one
since the block header has changed, how can we verify the block?

You can't, this is the point, you can't add a new transaction to an already solved block. That's what guarantees their integrity.
If you're still trying to solve a block, when you add a new transaction, you start hashing the new block header with the new merkle root.