Actual Process for Creating New BTC for Mining Reward

[sparcusa]

Hey Bitcoiners,  I have a question.    Can someone describe for me or point me to a detail description of the actual process for creating a mining reward?  I took a look at the mining code in github and I'm just not getting it.  I need specifics,  is it simply added to the UTXO from the block with addition of a valid hash?     Any help would be much appreciated.   Thanks !

[1714157579]

1714157579

[1714157579]

1714157579

[1714157579]

1714157579

[1714157579]

1714157579

[1714157579]

1714157579

[1714157579]

1714157579

[aleksej996]

This is best I could find for you
https://en.bitcoin.it/wiki/Transaction#Generation

[DannyHamilton]

I'm not sure what sort of technical details you are looking for.

To start with, if you are mining in a mining pool, then you typically have no control over the mining reward at all. The mining pool builds reward transaction, then assembles the block, and finally sends you the midstate after starting the hash process for you.

If you are solo-mining, then the software (typically Bitcoin Core) that you are using to feed your miners the work will handle all that for you.

As for specifically what the mining pool or Bitcoin Core are doing to "create the mining reward", they are simply building a transaction that has no inputs and which creates the appropriate outputs for the UTXO.

[sparcusa]

"they are simply building a transaction that has no inputs and which creates the appropriate outputs for the UTXO" 

Ok,  that's exactly what I'm trying to understand.    How does the process of building a transactions with no inputs create a valid amount of UTXO for the miners coinbase?   

In very broad strokes here

1 - Bitcoin Core node mine a winning hash
2 - Block is assembled from transactions in the mempool
3-  Block reward transactions is created
4 - Block is written to the chain
5 - CoinBase is populated with new UTXO

Questions
1 -  How is the verification of the winning hash done?
3 -  How is the actual mining reward transaction created and verified

I'm studying currency inflation mechanisms,  any incite would be greatly appreciated.     -Thanks

[Xynerise]

"they are simply building a transaction that has no inputs and which creates the appropriate outputs for the UTXO"

It means they are "creating" bitcoin out of thin air
Normally, in any transaction that's not a Coinbase transaction, the transaction MUST have inputs it references.
If A sends bitcoins to B, and B wants to send it to C, to spend the bitcoin, B must reference the output of the previous transaction (the one that A sent), and also if C wants to spend it, he must reference the output of the transaction he got from B, that would be the input of the new transaction, and so on.
(It should go without saying that a person can't spend more than the UTXO he uses as inputs contain)

 In a Coinbase transaction, however, there are no inputs to reference so it's like the bitcoins that are paid as mining rewards are created from thin air.

1 - Bitcoin Core node mine a winning hash
2 - Block is assembled from transactions in the mempool
3-  Block reward transactions is created
4 - Block is written to the chain
5 - CoinBase is populated with new UTXO

It doesn't have to be a bitcoin Core node, just any node that follows the protocol rules.
Also, 2 comes before 1.
The transactions in the mempool of the miner are aggregated before he tries to compute the proof-of-work.
Also, the Coinbase transaction (the one paying the miner the block reward and the fees of the transaction) is the FIRST transaction in the block always.

Questions
1 -  How is the verification of the winning hash done?

The winning hash is the one whose hash of block header + nonce is less than a given Target.
The target is known by all the nodes in the network and can be independently calculated and verified.
Finding the block header + nonce hash which is less than a given Target is the actual proof-of-work being done by the miner.

3 -  How is the actual mining reward transaction created and verified

1.) Miner aggregates all the transaction in the mempool that can fit in a block. (the transactions are hecjed for validity, adding an invalid transaction invalidates the whole block)
2) The Coinbase transaction (that pays him the block reward and fees for the transactions aggregated) is included first in this candidate block (not a real block yet because it hasn't computed the proof-of-work and found a "winning hash")
NB: the miner just can't pay himself any arbitrary amount GREATER than the block subsidy as the block reward because the subsidy is fixed and halves after a set number of blocks that corresponds to 4 years. The current is 12.5 BTC , if a miner pays himself a larger amount than that, even if he finds the winning hash, his work will be in vain because ALL the nodes in the blockchain will REJECT his block as invalid, because it does not obey the consensus rules, and thus it wouldn't even propagate far. The only way he can do this correctly and succeed is if he somehow convinces the WHOLE network -- or most -- to run his custom software that uses a different set of rules.
3)Add previous block hash as a reference.
 Summarise all the transactions in the block (including the Coinbase transaction) as a Merkle tree, add a timestamp, and the Target. Then the  nonce
5)4 above forms the block header, the miner then hashes this value while changing the nonce after each hash until the hash is less than the target.
If he finds one that is less than the target i.e the winning hash, he then "publishes" the block, which other miners and nodes verify. If it is valid according to the protocol rules, then other miners will mine on top of it, and the transactions in the block have 1 confirmation.
Then the race starts all over again.

However, this Coinbase transaction that pays the miner his rewards cannot be spent until after 101 confirmations (100 blocks). This is because, in case of a temporary fork where 2 miners find the winning hash at the same time, one will be invalidated and dropped by the network (the one with less proof of work). If this happens all the transactions in the orphaned block (that aren't in the validated block) that were heretofore confirmed will be sent back to the mempool. The Coinbase transaction can't be sent to the mempool since it isn't a valid transaction because it references no inputs, so it will disappear completely.
If the Coinbase maturation didn't exist, orphaned blocks would cause a problem for the network because coins that once existed would no longer exist.

I'm studying currency inflation mechanisms,  any incite would be greatly appreciated.     -Thanks

In that case you should read Andreas Antonopolous' book Mastering Bitcoin

[aleksej996]

The current is 25 BTC

You aren't keeping up with the times man, it has been 12,5 since 2016.

[Xynerise]

The current is 25 BTC

You aren't keeping up with the times man, it has been 12,5 since 2016.

Oops
Thanks.
Fixed.

[DannyHamilton]

"they are simply building a transaction that has no inputs and which creates the appropriate outputs for the UTXO"  

Ok,  that's exactly what I'm trying to understand.    How does the process of building a transactions with no inputs create a valid amount of UTXO for the miners coinbase?  

In very broad strokes here

1 - Bitcoin Core node mine a winning hash
2 - Block is assembled from transactions in the mempool
3-  Block reward transactions is created
4 - Block is written to the chain
5 - CoinBase is populated with new UTXO

Questions
1 -  How is the verification of the winning hash done?
3 -  How is the actual mining reward transaction created and verified

I'm studying currency inflation mechanisms,  any incite would be greatly appreciated.     -Thanks

Your understanding about how bitcoin works is not correct.  Xynerise has explained a lot of it.

Lets skip blocks for a moment and think about transactions.  As Xynerise explained, transactions spend previously unspent outputs, and create new unspent outputs.  They "spend previously unspent outputs" by referencing them as inputs.  Once an output has been referenced as an input in the blockchain, it is "spent" and can never again be referenced as an input in any other transaction.

Here's a nice analogy.  It isn't a perfect representation, but it makes it easier to visualize inputs and outputs at the transaction level. Don't try to stretch the analogy all the way back to the behavior of blocks and confirmations. Imagine that each output is a lump of gold...
So, if you receive three payments:
1 BTC, 0.75 BTC, and 1.5 BTC
Then imagine that as lump of gold worth 1 BTC, a lump of gold worth 0.75 BTC, and a lump of gold worth 1.5 BTC.

Now you want to pay someone 1.25 BTC.  Think of a transaction as a crucible in which you can melt and pour out lumps of gold.
You choose put the 1 BTC lump and the 0.75 BTC lump IN to the crucible.  These are the "inputs" into your transaction.  Then you turn on the fire and melt them.  You now have a crucible with 1.75 BTC worth of gold in it.  You pour OUT a 1.25 BTC lump of gold for the payment that you want to make.  You still have 0.5 BTC worth of gold left in the crucible.  Therefore, you pour OUT a second lump of gold worth 0.5 BTC and keep that for yourself.  The original 1 BTC and 0.75 BTC lumps of gold are gone.  They've been "spent" as inputs.  Meanwhile two new outputs have been created (a 1.25 BTC output that you gave to the person you were paying, and a 0.5 BTC "change" output that you kept for yourself.  If you choose to leave any gold in the crucible, then that becomes a transaction fee that the miner can mix into his coinbase crucible and include when he pours out his reward for himself.  So, if you have only poured out a 0.49 BTC output for yourself, then there would have been 0.01 BTC worth of gold left in the crucible that the miner could scrape out and keep as a fee.

As for the "coinbase transaction" (also called the "generation transaction").  Imagine that the miner has a magical crucible. It is magically linked to all the other bitcoin crucibles that everyone else uses.  It starts out empty, but when he tips it over it pours out some gold.  Notice that he didn't put any gold IN it (there are no inputs), and yet some new gold comes OUT.  It creates new outputs.  You can see how this special crucible creates inflation (an increase in the total amount of gold in the world). This is where the analogy starts to fall apart a bit.  The miner doesn't include the transaction fees as inputs. He does NOT put the gold from all the transaction crucibles INTO his coinbase crucible.  Instead all the transaction fees from all of the transaction crucibles just disappear from all of their crucibles, and the amount of gold that pours out of this magical crucible is the current subsidy PLUS all those fees.  Don't try to push this part of the analogy too far.  There are conditions on how this coinbase crucible works and the analogy completely falls apart when you look at how blocks work (the output vanishes and the fees all go back to the transaction crucibles if the block is not included in the blockchain, the fees that pour out are only the fees of the transactions that were included in the block, multiple miners can all pour out the same fees at the same time while they are building their block, but only the fees of the block that makes it into the blockchain continue to exist, all the others vanish or go back to their transaction crucibles)

As has been explained by Xynerise, the bock process involves 5 steps in the following order:

• 1. Choose a set of valid unconfirmed transactions for your block.
• 2. Build your coinbase transaction with no inputs and paying outputs that sum to no more than the sum of the current subsidy (12.5 BTC right now) plus the transaction fees from all of the transactions selected in step 1.
• 3. Build the block header which references it's previous block, and has a merkle root commitment for the transactions of steps 1 & 2
• 4. Complete the proof of work on the block header created in step 3.
• 5. Broadcast the block completed in step 4 to all connected peers, and go back to step 1.

If at any time you receive a valid block from a connected peer, you need to abandon the block you are working on and immediately go back to step 1.

If at any time you discover that the block you are working on has no valid solution, then you need to modify your block header.  This can be done by going back to step 3, 2, or 1.
In step 3 the block header can be modified by adjusting the block timestamp.
In step 2 the block header can be modified by adjusting the extranonce (a value is stored in the coinbase transaction in place of the missing inputs). After this you proceed to step 3 and have a different merkle root since the merkle root is based on this new data.
In step 1 the block header can be modified by adjusting the transaction selection or ordering. After this you proceed to step 2 since the new transaction selection might have a different transaction fees sum.  Then you proceed to step 3 and have a different merkle root since the merkle root is based on this new data.