How do miners actually collect commission for creating a block?

[BoyFromDubai]

I've just looked through Blockchain.com and looked through transactions in a block. And neither a lot of outputs were in the coinbase transaction nor the last transaction was with lots of outputs. So how does miner actually collects commission?

[Charles-Tim]

A miner mine a block and the miner is given the reward. The miner can do anything with the rewards.

This is an example: https://www.blockchain.com/explorer/blocks/btc/767547

Block 767547
The reward for block mined is 6.25 BTC
The reward for including transaction into the block mined is: 0.13448374 BTC
Reward in total which would be on the miners address(es) (block reward + transaction fees): 6.38448374 BTC

[witcher_sense]

I've just looked through Blockchain.com and looked through transactions in a block. And neither a lot of outputs were in the coinbase transaction nor the last transaction was with lots of outputs. So how does miner actually collects commission?

Transaction fees aren't included in a transaction and rather calculated implicitly: essentially it is a surplus (or difference) of bitcoin between total sum of inputs and total sum of outputs. When miners calculates his reward, he adds up this surplus to block subsidy and collects block reward.

You can read more here: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch10.asciidoc

[bitmover]

I've just looked through Blockchain.com and looked through transactions in a block. And neither a lot of outputs were in the coinbase transaction nor the last transaction was with lots of outputs. So how does miner actually collects commission?

As Charles-Tim pointed out, it is part of the Coinbase transaction, the first transaction in a block.

Block Reward = subsidy + fees

You can also read it in the whitepaper:

By convention, the first transaction in a block is a special transaction that starts a new coin owned
by the creator of the block. This adds an incentive for nodes to support the network, and provides
a way to initially distribute coins into circulation, since there is no central authority to issue them.
The steady addition of a constant of amount of new coins is analogous to gold miners expending
resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.

The incentive can also be funded with transaction fees. If the output value of a transaction is
less than its input value, the difference is a transaction fee that is added to the incentive value of
the block containing the transaction. Once a predetermined number of coins have entered
circulation, the incentive can transition entirely to transaction fees and be completely inflation
free.

https://bitcoin.org/bitcoin.pdf

[NotATether]

The bitcoin network is hardwired to accept the first transaction placed inside a block that contains (BLOCK_SUBSIDY) amount more bitcoins in total outputs than inputs.

Miners can choose to not claim the reward, but they will never be able to take that coinbase reward again if they do.

[BoyFromDubai]

I got
Thanks to all of you!!!


But I've got another question
For a miner coinbase transaction contains always the same information (If we don't consider the division by 2 the number of bitcoins for mining). But txid for this transaction always different. that's because of fees? This time I've got 1 bitcoin in fees, the next time I've got 1.1 bitcoins. And tx information for me is always the same, excluding the reward. If I've got correctly, txid always different because of fees, isn't it?

[moderator's note: consecutive posts merged]

[NotATether]

But I've got another question
For a miner coinbase transaction contains always the same information (If we don't consider the division by 2 the number of bitcoins for mining). But txid for this transaction always different. that's because of fees? This time I've got 1 bitcoin in fees, the next time I've got 1.1 bitcoins. And tx information for me is always the same, excluding the reward. If I've got correctly, txid always different because of fees, isn't it?

The Txid is just the hash of the raw transaction data that is encoded in binary.

You might see such transactions represented as hex or as rich-text fields, but it is not hashed like that. It has to be represented as the 8-bit binary that will usually contain unreadable/non-printable characters.

[BoyFromDubai]

Yeah, I know that. But I'm interested in why hash of tx data of one miner always different? All information in coinbase tx the same for one miner excluding the reward that consists of  block reward + number of fees he gets from the block?

[garlonicon]

But txid for this transaction always different. that's because of fees?

No, it is because the block number is included. And each block has a different number. See: BIP-34

For example, before BIP-34, it was possible to create duplicated coinbase transactions. See also: BIP-30.

[BoyFromDubai]

Hmm
Then, this article is a bit old and doesn't show the current way of creating transacctions?
https://learnmeabitcoin.com/technical/transaction-data
I mean, now the structure of transaction is different?

[garlonicon]

I mean, now the structure of transaction is different?

It is compatible, so those things are still valid. Because if some old standard timelocked transaction was created in the past, it has to be valid today.

Of course, we have Segwit on top of that. It means, the coinbase transaction is different, and you can read more in other BIPs, like BIP-141. In general, Segwit transaction has just the same structure as non-Segwit transaction, but it also has some witness data, that are not processed by older, non-upgraded nodes.

[hosseinimr93]

The Txid is just the hash of the raw transaction data that is encoded in binary.

To be more accurate, the transaction hash is calculated by hashing the transaction data through SHA256 function twice.

Yeah, I know that. But I'm interested in why hash of tx data of one miner always different?

According to BIP34, the coinbase transaction must contain the block height.
Before implementation of BIP34, it was possible to duplicate a coinbase transaction.

[BoyFromDubai]

But what did happen before this BIP? Two coinbase transactions with the same txid, it's a collision. How to save two coinbase vouts into leveldb and how to spend one of them if they have the same txid?
 

[hosseinimr93]

But what did happen before this BIP? Two coinbase transactions with the same txid, it's a collision. How to save two coinbase vouts into leveldb and how to spend one of them if they have the same txid?

With BIP34, it's very very unlikely that two coinbase transactions have the same ID, but in theory it's still possible that two transactions have the same transaction ID.
If a transaction has the same ID as an existing transaction, the second one would replace the first one and there wouldn't be any way to spend the fund received in the first one.
See blocks number 91,722 and 91,880. The coinbase transactions in these two blocks have the same ID. The person who received the block reward on block number 91,722 can't spend it.
The solution to this problem was BIP30. According to BIP30, a block can't include a transaction with the same ID as a not-fully-spent transaction.

[NotATether]

But what did happen before this BIP? Two coinbase transactions with the same txid, it's a collision. How to save two coinbase vouts into leveldb and how to spend one of them if they have the same txid?

The thing is that the network will accept only the first coinbase transaction in the block (which HAS to be the first transaction). Everything else is invalid from a protocol standpoint, even if two coinbase transactions are included in a block.

[hosseinimr93]

The thing is that the network will accept only the first coinbase transaction in the block (which HAS to be the first transaction). Everything else is invalid from a protocol standpoint, even if two coinbase transactions are included in a block.

I think OP is talking about two coinbase transactions with the same ID in two different blocks, not in the single block.

In theory, it's possible that a block includes a transaction with the same ID as an existing transaction if the existing transaction has been fully spent. Whether it's a coinbase transaction or a normal transfer, there's nothing prevent network from accepeting such a transaction.
Before implementation of BIP30, a block could include a transaction with the same ID as an existing transaction, even if the existing transaction had been unspent.

[pooya87]

For a miner coinbase transaction contains always the same information

There are many variables in a transaction. The only thing that must always be the same is the outpoint of a coinbase transaction's only input. The other thing that must be different is the coinbase's signature script. The rest can be different (tx version, number of outputs, the outputs and the rest of the input's signature script).

If a transaction has the same ID as an existing transaction, the second one would replace the first one and there wouldn't be any way to spend the fund received in the first one.

It used to be like this, but today if this happens the transaction and the block containing it will be rejected as invalid. Note that this is a general rule not just for coinbase txs and BIP30 only prevented coinbase duplication.

even if two coinbase transactions are included in a block.

That has always been impossible because a coinbase tx spends a special input (null hash with -1 index) which is not possible to see in any other tx. So you can't have 2 coinbase transactions in a block regardless of what BIP30 did.

[hosseinimr93]

It used to be like this, but today if this happens the transaction and the block containing it will be rejected as invalid.

But we can still have a block including a transaction with the same ID as an existing transaction, if the existing transaction has been fully spent. Right?
I know the chance of that happening is almost zero.

[NotATether]

The thing is that the network will accept only the first coinbase transaction in the block (which HAS to be the first transaction). Everything else is invalid from a protocol standpoint, even if two coinbase transactions are included in a block.

I think OP is talking about two coinbase transactions with the same ID in two different blocks, not in the single block.

Most full nodes should be able to detect this anomaly very quickly, since the UTXO sets will not be identical, and that will cause problems and validation errors when verifying child transactions.

[pooya87]

It used to be like this, but today if this happens the transaction and the block containing it will be rejected as invalid.

But we can still have a block including a transaction with the same ID as an existing transaction, if the existing transaction has been fully spent. Right?
I know the chance of that happening is almost zero.

Yes.
Your node only checks the UTXO database to see the transaction can be found among the unspent outputs not the whole blockchain. It would take a long time to search the entire blockchain that is not indexed anyways.
I believe this is the line where it rejects such transactions if they exist among "coins": https://github.com/bitcoin/bitcoin/blob/968f03e65c98a9a36aea6c57a29306839b0ada57/src/validation.cpp#L2151