Updated bitcoin miner client flowchart - is this correct now?

[bitcoinflea]

Admins, kindly permit this post - to everyone else, respect this please...

I've made a diagram here about a mining software (be it for solo-mining or mining pool) connecting to any variant of the bitcoin network. I like to know if I diagrammed it correctly.

https://imgur.com/6zVxxfS
(in case you can't see the image, go here - Back-up link to flowchart image https://imgur.com/6zVxxfS)

I am aware that solo-mining is a stupid endeavor and setting up mining pools is just not so profitable any more - but I'm more on the software side and I want to understand how a mining client works.

I understand how the blockchain works (thanks to the Simply Explained YouTube channel) but one thing I'm still trying to figure out is how the crypto-miner connects to the internet for the mining operation and how it also connects to the net to load the coin rewards into the miner's wallet.

Feel free to talk about this thread - just no stupid offers to invest in bitcoins or other crap. I don't own ANY crypto-coins and I'm only into programming - 'nuff said.

[NotATether]

Looks fine to me. You'd use a mining software such as cgminer and connect it to your local bitcoin node at localhost:8332 (the json-rpc port). Connecting to a mining pool is similarly simple you have to pass it an IP address/port/username/password.

It is possible to run Bitcoin Core without wallet support by setting disablewallet=1 in bitcoin.conf, and to send the mining rewards to some hardware wallet's address (safer).

[BrewMaster]

if by software you mean the bitcoin node, then they don't have to be restricted to port 8333 (or the small range which i don't know where you got from) in fact there are nodes that use other ports such as 8555,  7333, etc. as long as the port number doesn't cause any kind of conflict with some other app it is fine.

i would replace "is hash legit?" with correct term "is hash below target"

you don't broadcast "new blockchain ledger" you only broadcast the new block.

you are again putting the "fetch wallet" and "add reward to wallet" after mining is done but it should be before mining starts.

[mocacinno]

Why would we disrespect your work? You're clearly interested and making an effort, and that's always a good thing

I sent you a merit because i'd like it if you stayed in the community, we're always interested in people that show the willingless to learn!

That being said, there are a couple things in your diagram that strike me as odd:

1) you have a loop between "mine blockchain for reward" and "is hash legit". This is true, but the loop should actually go back even further: As soon as your node receives a new block, it should be verified and you should start your mining process all over. The way your flow diagram is created now will continue mining UNTILL you find a valid header, EVEN if you receive new, valid blocks

2) the "fetch the miner's wallet" isn't 100% correct terminology, but even if we disregard this, the step is not placed in the correct place: when mining, you're searching for a nonce for which the sha256d hash of the header is under the current target. The block header you're iterating over contains the merkle root right from the start, so you should know which address you want to be funded if you solve a block BEFORE you start hashing.

3) it's perfectly possible to use an address that's not belonging to your wallet to receive the coinbase reward... There is no need to "add reward to miner's wallet"

Solo mining is basically:
Building an utxo set and filling your mempool with unconfirmed transactions
=>
Receive a new block, update your utxo db and mempool
=>
Select the top 1Mb (not countig witness data) transactions from your mempool and create a block. Add the coinbase transaction funding your own address with the current block reward + fees from the selected transactions (fee = sum of the value of all the inputs minus the sum of the value of all the outputs)
=>
create the block header (including the hash of the previous's block header, the root of the merkle tree of all tx's selected in the previous step, the nonce and some extra data)
=>
Iterate over the nonce untill you find a block header whose sha256d hash is under the current target OR untill a new valid block is received by your node (if you receive a new valid block, go back to the second step of this list)


A secondary loop should continue receiving broadcasted transactions to keep filling your mempool

pool mining is basically:
The last step of solo mining

[aliashraf]

I'm afraid it is not a good representation of mining neither for solo mining nor (by any means) for pool mining. I think you need to distinguish between the two very strongly because a solo miner runs a bitcoin full node while a pool miner has no clue about the original bitcoin network because he receives work through Stratum protocol from pool service unlike a solo miner (a rare entity nowadays) who continuously builds a mine-able block from the latest bitcoin blockchain status and the mempool. Your diagram fails to demonstrate the solo mining process and has nothing to show about pool mining.

It is also important to note that miners do not fetch their rewards from anywhere unlike what you've suggested, it is built to the block from the first place (in a special transaction called coinbase).

I strongly recommend a more detailed review of bitcoin before proceeding anymore.

[ranochigo]

Your previous thread: https://bitcointalk.org/index.php?topic=5304116.0. I didn't receive any response from you but please let me know if you didn't understand any parts of my explanation.

To correct again, the mining software doesn't interfere with the wallet nor 'pays' the miner's rewards. The most it could do is to specify the coinbase transaction and the outputs which are already decided before a valid block is mined.

[bitcoinflea]

Your previous thread: https://bitcointalk.org/index.php?topic=5304116.0. I didn't receive any response from you but please let me know if you didn't understand any parts of my explanation.

To correct again, the mining software doesn't interfere with the wallet nor 'pays' the miner's rewards. The most it could do is to specify the coinbase transaction and the outputs which are already decided before a valid block is mined.

I'm having a hard time updating the graphic for the flowchart. Had it been so easy to upload replies with revised illustrations in the thread, I would have stuck to the old thread.

So I was forced to create this new thread.

It was not my intent to disrespect you - there really are a lot of constraints to putting up replies with illustrations.

I'm more of a visual learner - pure talk and pure text replies make it hard for me to understand even the most basic concepts.

My apologies, and please bear with me...

[bitcoinflea]

I wanted to make a graphic again so I can better illustrate it but this forum doesn't allow me to.
I'll list down what I undestand to be the exact steps, based on what all your replies in the thread tell me...

Step 1 -  activate mining hardware

Step 2 -  start mining software

Step 3 -  software connects to port 8332 or any available port; listen for active nodes

Step 4 -  connect to active node

Step 5 -  download new updated blockchain ledger

Step 6 -  fetch miner's wallet

Step 7 -  add reward to miner's wallet

Step 8 -  Get the 1MB head of the blockchain ledger

Step 9 -  Begin mining

Step 10 -  Is hash below target?

> if no, return to step 9

> if yes, go to step 11

Step 11 -  broadcast the new block

Step 12 -  Do you wish to continue mining?

> if no, return to step 8

> if yes, go to step 13


If there are any mistakes, just tell me...

By the way, I'm puzzled as to where the following lines go to in the steps I listed (from mocacinno's reply):

Building an utxo set and filling your mempool with unconfirmed transactions
=>
Receive a new block, update your utxo db and mempool
=>
Select the top 1Mb (not countig witness data) transactions from your mempool and create a block. Add the coinbase transaction funding your own address with the current block reward + fees from the selected transactions (fee = sum of the value of all the inputs minus the sum of the value of all the outputs)
=>
create the block header (including the hash of the previous's block header, the root of the merkle tree of all tx's selected in the previous step, the nonce and some extra data)
=>
Iterate over the nonce untill you find a block header whose sha256d hash is under the current target OR untill a new valid block is received by your node (if you receive a new valid block, go back to the second step of this list)


A secondary loop should continue receiving broadcasted transactions to keep filling your mempool

[NotATether]

By the way, I'm puzzled as to where the following lines go to in the steps I listed (from mocacinno's reply):

Building an utxo set and filling your mempool with unconfirmed transactions
=>
Receive a new block, update your utxo db and mempool
=>
Select the top 1Mb (not countig witness data) transactions from your mempool and create a block. Add the coinbase transaction funding your own address with the current block reward + fees from the selected transactions (fee = sum of the value of all the inputs minus the sum of the value of all the outputs)

There are two types of mining rewards, the coinbase reward is the one that gives miners 50BTC, 25BTC, 12.5BTC etc, and then there is the transaction fee reward, where a miner collects the transaction fee of all the transactions included in his block. Miners almost always include a set of transactions in their newly mined block.

Rarely, they run out of time to construct an unconfirmed transaction set and so they broadcast an empty block without one, and just a coinbase reward. You see this happen when a miner finds a block before they finish making the transaction set. The reason they broadcast an empty block instead of finishing construction is so that they can be the first to broadcast a block and thus get the mining reward. Miners obviously don't want another miner to broadcast their own block first, when they themselves already have a solved block.

=>
create the block header (including the hash of the previous's block header, the root of the merkle tree of all tx's selected in the previous step, the nonce and some extra data)

The block header is just a field inside the data structure of a block, and the block header is a data structure itself with fields that @mocacinno mentioned.

=>
Iterate over the nonce untill you find a block header whose sha256d hash is under the current target OR untill a new valid block is received by your node (if you receive a new valid block, go back to the second step of this list)

This is the step "mine blockchain for reward" in your flowchart.

The verification check that a block's SHA256d is under the target corresponds to the step "is hash legit".

A secondary loop should continue receiving broadcasted transactions to keep filling your mempool

Basically the "download new blockchain ledger" step runs in parallel to the other steps, and an update of the ledger (by receiving new transactions) causes the flowchart to halt and go back to "mine blockchain for reward".