Bitcoin Forum

These has always been a difficulty for me!! But i guess ill look beyond it today.
Hello great GURUS ❤
I had a very tough question on my mind to share
 Every bitcoin transaction is made of inputs and outputs.
While output creates new UTXO(unspent transaction output),inputs also tends to consume existing UTXOs  
Literarily,it means UTXOs are created through the consumption of other UTXOs.Then if old UTXOs are destroyed to create new UTXOs, how then are UTXOs created in the first place or instance?
Thanks for help and replies 🙏
Trojane💎
 

Coinbase transactions (coin generation transactions not to be confused with transactions created using Coinbase the service) are special transactions which can create outputs without consuming any outputs as inputs. They are created by miners and are not allowed to be more than the block subsidy plus transaction fees. All UTXOs can be traced to have originated with an output from a coinbase transaction.

Does it really mean that UTXOs are created by MINERS only during output transactions as you said or is there any other way it could be generated?

Yes, the UTXOs that don't spend previous UTXOs can only be created by miners in their coin generation transactions.

Only 1 such transaction is permitted in each block, and the sum total value of the outputs in that special transaction is not permitted to exceed the total value of the current block subsidy (6.25BTC) plus the sum of all transaction fees of all transactions in the block.

Additionally, coinbase transaction could have lots of output (which create lots of UTXO). Here's an example, https://blockchair.com/bitcoin/transaction/40db01e4bc0a3cc63cd0f08d310bdb624ad343ab72bfc2716b28bd40452a6dbe (https://blockchair.com/bitcoin/transaction/40db01e4bc0a3cc63cd0f08d310bdb624ad343ab72bfc2716b28bd40452a6dbe).


Not "tends", but "always".

This is more simple than it looks like.

Coins (UTXO) need to be created first to be consumed later on.

As achow101 said, the only way to generate new coins is by mining blocks in the process called proof of work.

When the miner solves the proof of work algorithm, he creates a new block and receives the Coinbase transaction, a special transaction that doesn't have any inputs, generating new coins.

This is how all bitcoins were generated in the first place. When the first block was mined, the first 50 bitcoins were generated (the block subsidy at the time). And since then, every 10 minutes (on average) we have new coins being generated. This is the only way to create new coins.

In the future creating new blocks won't generate new coins, this is why bitcoin has a limited supply of coins.

The miner (or pool) doesn't "receive" the Coinbase transaction, they "CREATE" it.  It's part of the process of creating a block.

Additionally, the miner (or pool) creates the new block before they begin the work.  Once they complete the work on the block (arriving at a nonce that proves that they did the work), they broadcast the block.


Worth explaining to those that don't already understand the process, the special transaction with outputs and no inputs will still in blocks exist at that time.  The difference is that the sum of the value of the outputs will be required to be equal to (or less than) the sum of the value of the transaction fees of all the transactions in the block.  Therefore, "miners" will still be compensated. They'll just earn their revenue from transaction fees instead of the inflationary subsidy.

(Italicized edited for clarity.)

The sum of the outputs of the coinbase transaction will be required to be less than or equal to the sum of the fees. There is no requirement for a miner to claim the full block subsidy or the full amount of fees - they are only prevented from claiming more than the limit, but not from claiming less. There have been a number of bitcoin permanently lost through miners claiming less than they were allowed to. For example, block 501,726 (https://mempool.space/block/0000000000000000004b27f9ee7ba33d6f048f684aaeb0eea4befd80f1701126), where the miner failed to claim any of the 12.5 BTC block reward.

What?
Without any bitcoin being generated, how can it be a valid block then? Where's that 12.5 BTC now?
Assuming that's the only block in which the miner didn't claim the block reward, the maximum supply of bitcoin should be 20999987.5 and that 12.5 BTC doesn't exist in the blockchain at all?

Because there is no requirement for coinbase outputs to spend the maximum allowed amount of bitcoin, or indeed, any bitcoin at all.

Irretrievably lost.

Yes, that 12.5 BTC is lost forever, but it is definitely not the only time bitcoin have been lost in this manner. As another example, block 526,591 only generated 6.25 BTC instead of the 12.5 BTC allowed.

Yep. Thanks.  Can't believe I forgot to state that.  Clearly it's not commonly known and important as the recent few comments demonstrate.

It's indeed kinda weird why we'd accept such block as valid, but you should see it from another side. The block rewards money that will be owned by the miner. They'll be possessed by the miner and they can choose to do whatever they want with them. It'd be idiotic to consider wrong a case where the miner doesn't earn the whole reward.

Even if we did, the miner could still burn them, such as with OP_RETURN, and make them disappear from circulation. It'd just fill the block chain with an extra, unnecessary transaction.

I suspect that in the vast majority of cases where the miner has not claimed the full amount it was by mistake rather than by choice. Much like when we see those transactions paying fees of several bitcoin, where people have tried to create a transaction manually to send a trivial sum, forgetting that anything not accounted for in the outputs or sent to a change address is automatically included in the fee. There were lots of cases back in 2012 where miners claimed the full 50 BTC block reward, but neglected to claim any of the additional fees they were due, presumably because of a bug with their mining software.

This makes me wonder whether the transaction fees are lost somewhere and can ever be reclaimed.

They are not "lost" in the sense of coins being sent to a burn address with an unknown private key are "lost", in the way that they still exist but no one can spend them. Rather, they are permanently destroyed. The output(s) from these coinbase transactions, even if they were allowed to contain x amount of bitcoin, only contained x-y amount of bitcoin, and so there only exists x-y amount of bitcoin to be spent and used.

Of course, it would be possible in the future to change the code so future blocks could add on the lost coins to their own their own block reward, but I don't see there ever being consensus to do that, just as there would not be consensus to raise the 21 million cap or allow OP_RETURN coins to be reclaimed.

Unless there is some sort of catastrophe where a large percentage of the total circulating bitcoin supply is provably burnt (and I'm talking about a huge amount such as 19-20 million), we can't even begin to talk about possibility of "re-introducing" lost coins. Until then anything that is lost is a donation to the rest of us since it slightly increases bitcoin scarcity.

My technical knowledge is scarce and I am forcing myself lately to read some of these technical threads to see if I can learn more.

My understanding is that OP was asking a chicken or the egg question:



This false dilemma would be solved by coinbase (I'm not confusing it with the company):


But another dilemma has arisen for me while reading the thread:



In that transaction I see a "sender 0", which would be Coinbase, and 721 recipients.

Are the 721 transactions

1) those that miners validate in that block? or

2) is the miner sending the reward to 721 different addresses?

At first I thought it was the 1), but then I go in to see the transactions, and for example, the first two addresses, received a certain amount of Bitcoin and have not spent it in 10 years. The third and fourth ones did spend. Not clear to me. Also, I think if they were the transactions that miners validate they would have a sending address and a receiving address instead of "sender 0 Coinbase".

And the miner sending the reward to 721 different addresses (2) doesn't seem logical to me either.

Why not? This is from early years of mining pools (the first one started in November 2010, and this is ~7 months later from an unknown miner) and this particular one might have been experimenting with direct payments to its miners where they get paid based on their share instead of letting it accumulate in their account and then withdraw once.

Probably because my knowledge of the subject is considerably less than yours.


All clear, I guessed that the fact that it was such an old transaction had something to do with it but I couldn't imagine what.

Option 2 as explained by pooya.

Just to expand on what you suggested for option 1 - the outputs in a coinbase transaction have nothing to do with the other transactions which are included in that block. The majority of coinbase transactions now include a single output containing the block reward and all the fees they are claiming, plus a few additional OP_RETURN outputs, usually marking the name of the mining pool which found the block. If the miner chooses to split the subsidy between multiple addresses (even between several hundred addresses as we've seen here) instead of just sending it to a single one, then they are free to do so. This has no bearing on the other transactions included in the block. A block with 1000 transactions could send the whole block reward to a single address, and an empty block with no other transactions could split the block reward across 1000 addresses.

Since you're trying to learn, and interested in discussing things at a technical level, I'll point out that that isn't 721 transactions.


That's 1 transaction, with 721 outputs.

I have learned from this discussion and it's very interesting.
Can you hide your email from your profile, I think it's good if it remains hidden.

Go to Profile >> Account Related Settings >>  Hide email address from public?  tick the check and save changes, that's all.