Need help for understanding block formation

[3rek0s3]

Hi everyone, wish you a happy new year.
As I am new to the bitcoin stuff I have a loads of n00b questions and I would like to have your opinions and guidance.
First of all, I intend to develop a simple miner in python3, of course not for the purpose of making any money since ASICs are now the bare minimum, but for getting a decent understanding of what is done and how.

I started with the installation of the bitcoin core (22.0) stuff and run a full node with incoming connections.
Then I tried to find a python miner to look at the code, of course they are some, especially this one : https://github.com/jgarzik/pyminer/blob/master/pyminer.py

However this one uses the pre 2012 ‘getwork’ rpc meaning that it does not work anymore (and it’s python 2 anyway).
Thus I started to look at the ‘getblocktemplate’ rpc as this should be its acknowledged replacement. From what I understand, it is more complicated but gives miners/pool more visibility on what is mined.
Of course, mining is linked to the block building and block header mining. So to build a block for my solo miner I have to build a block from scratch querying my full node.
 
Basically it should amounts to select pending transaction obtained from ‘getblocktemplate’ and  first to build the ‘coinbase’ generating transaction. This very one isn’t clear to me as it should contain an op (since it is a specific generating one), it should contain a bitcoin address (mine would be better) and an amount of BTC. If I am not mistaken, it should be the reward for the block (6.5 BTC currently?) plus the sum of the selected transaction fees.
From my understanding, a part of this very transaction can be used as an ‘extranonce’, since part of it is not strictly used for the transaction but as it modifies the content of the block, it also modifies the base merkle tree hash of the block, seen in the block header. This implies (and it was not clear to me) that every miner (unless in a pool ?) work on a different block header, even if they have selected the very same pending transactions to build their block, since their bitcoin address and possibly chosen extra nonce  changes the block header.

Any pointer (code, step by step tutorial) explaining clearly how to ‘binary’ build this first transaction would be great.
It is also not clear to me how the double sha-256 is used since sha-256 works on batches of 512 bits reusing the previous obtained hashes. Are their several rounds (in the first pass) necessary for this transaction ? I believe that in the 2nd sha-256 pass, only the obtained ‘digest’ is used thus one round is enough (thus with the default hash values as it is considered a ‘new’ message).

Ok thanks for reading and I hope some of you have pointers for me

[1714816563]

1714816563

[1714816563]

1714816563

[pooya87]

I can't comment on RPC commands since I'm not fully familiar with them and also it won't help you understand how things work if you are using these commands that do everything for you.

To mine a block you have to start by selecting transactions from your mempool to include in that block. Generally you select them based on the fee they are paying to maximize your revenue. You also have to select as many transactions until the total block weight is smaller than or equal to 4000000.
Now you finalize the first transaction in your block (the coinbase transaction):
- by setting its output amount equal to block subsidy + sum of fees from all transactions.
- computing and setting the witness hash merkle root of all transactions if at least one transaction in that block had any witnesses.

Then you can finish the block header by computing the merkle root and setting it.

Finally you start computing double SHA256 hash of the header and comparing it with target. If it were > target you increment the nonce in header and repeat the steps. If it were <= target then you have successfully found the correct combination and can submit the block to the network.
If you incremented nonce to its max and still hadn't found the result you change the header (time or version) or the block content (that would change merkle root) and repeat the above steps again. The block content that can be changed are the transactions (select different ones from mempool or change their orders) or your coinbase tx (the contents of its signature that usually referred to as extranonce).

This very one isn’t clear to me as it should contain an op (since it is a specific generating one), it should contain a bitcoin address (mine would be better) and an amount of BTC. If I am not mistaken, it should be the reward for the block (6.5 BTC currently?) plus the sum of the selected transaction fees.

I'm not sure you mean by "op". Coinbase transactions should:
- Have one and only one input with its outpoint set to an empty hash and max index (0xffffffff)
- Have a signature script that contains the block height at the start and is no larger than 100 bytes
- Has at least one output
- Total output amount can not exceed the block subsidy + sum of all tx fees (but it can be lower)

The block subsidy is computed based on the block height and halving that takes place every 210000 blocks and starts at 50.
50 /2 = 25 /2 = 12.5 /2 = 6.25 /2 = ...
So it currently is 6.25

This implies (and it was not clear to me) that every miner (unless in a pool ?) work on a different block header, even if they have selected the very same pending transactions to build their block, since their bitcoin address and possibly chosen extra nonce  changes the block header.

Normally the order of transactions in blocks created by different pools, the selected transactions and the outputs of the coinbase transaction are different.

It is also not clear to me how the double sha-256 is used since sha-256 works on batches of 512 bits reusing the previous obtained hashes.

You compute SHA256 of the 80-bytes (the header) and get a 32-byte result. Then compute SHA256 hash of that result to get your final hash.

Are their several rounds (in the first pass) necessary for this transaction ?

To be clear in PoW you compute the hash of the header not the transaction.