Bitcoin Forum

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?

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

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

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:

https://bitcoin.org/bitcoin.pdf

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.

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]

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.

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?

No, it is because the block number is included. And each block has a different number. See: BIP-34 (https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki)

For example, before BIP-34, it was possible to create duplicated coinbase transactions. See also: BIP-30 (https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki).

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?

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 (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki). 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.

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


According to BIP34 (https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki), the coinbase transaction must contain the block height.
Before implementation of BIP34, it was possible to duplicate a coinbase transaction.

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 (https://www.blockchain.com/btc/block/91722) and 91,880 (https://www.blockchain.com/btc/block/91880). 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 (https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki). According to BIP30 (https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki), a block can't include a transaction with the same ID as a not-fully-spent transaction.

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.

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).

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.

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.

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.

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.

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

In the first place dude, what does the bitcoin miners do? as far as I know these miners are producing valid blocks, and there are some bitcoin miners such as to full and to pull slush and so on. Aside from that they will be looking at this transaction buffer get the block of transaction you know like 2 to 3 megabyte or that there is block limit so they get certain amount of transaction they start mining it. And once its start, it produce hash anyway.

In short, its not like you're mining and then later or someone transfer you the money. As part of the mining process itself you add a reward to yourself in that block and as far as we all know it's a guessing game so you have nonce is equal to 1, 2 or 3 something like that.