How do miners actually collect commission for creating a block?

gunhell16

hero member

Activity: 1904

Merit: 541

Quote from: BoyFromDubai on December 15, 2022, 11:49:36 AM

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?

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.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: hosseinimr93 on December 16, 2022, 12:03:01 AM

Quote from: pooya87 on December 15, 2022, 11:19:47 PM

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

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: hosseinimr93 on December 15, 2022, 10:50:27 PM

Quote from: NotATether on December 15, 2022, 10:18:58 PM

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.

hosseinimr93

legendary

Activity: 2380

Merit: 5213

Quote from: pooya87 on December 15, 2022, 11:19:47 PM

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.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: ?? on ??

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

Quote from: hosseinimr93 on December 15, 2022, 05:37:58 PM

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.

Quote from: NotATether on December 15, 2022, 10:18:58 PM

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

legendary

Activity: 2380

Merit: 5213

Quote from: NotATether on December 15, 2022, 10:18:58 PM

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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: BoyFromDubai on December 15, 2022, 05:13:38 PM

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

legendary

Activity: 2380

Merit: 5213

Quote from: BoyFromDubai on December 15, 2022, 05:13:38 PM

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.

BoyFromDubai

jr. member

Activity: 33

Merit: 22

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

legendary

Activity: 2380

Merit: 5213

Quote from: NotATether on December 15, 2022, 01:55:38 PM

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.

Quote from: BoyFromDubai on December 15, 2022, 02:19:31 PM

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.

garlonicon

copper member

Activity: 821

Merit: 1992

Quote

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.

BoyFromDubai

jr. member

Activity: 33

Merit: 22

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

copper member

Activity: 821

Merit: 1992

Quote

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

jr. member

Activity: 33

Merit: 22

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?

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: ?? on ??

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

jr. member

Activity: 33

Merit: 22

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

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

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.

bitmover

legendary

Activity: 2352

Merit: 6089

bitcoindata.science

Quote from: BoyFromDubai on December 15, 2022, 11:49:36 AM

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:

Quote

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

witcher_sense

legendary

Activity: 2464

Merit: 4415

🔐BitcoinMessage.Tools🔑

Quote from: BoyFromDubai on December 15, 2022, 11:49:36 AM

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

Charles-Tim

legendary

Activity: 1512

Merit: 4795

Leading Crypto Sports Betting & Casino Platform

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

Topic: How do miners actually collect commission for creating a block? (Read 230 times)