Technical questions in trying to understand bitcoin.

[wonkelteut]

Hello,

I'm trying to understand the workings of bitcoin on the technical side, and I have a few questions which are probably beginners questions as they must have been extensively treated "back then".   So I put this in the "beginners" forum.  I appologize if this is not the right place, I hope a moderator will tell me where such things should be discussed then.

The first is the softforks regarding bip30 and bip34.
I understand that the coinbase transaction, given that it doesn't need any real inputs, can (could) always be exactly the same if the miner decided so (with the same output address, and the same sigscript), and so would result in the same hash, hence the same TXID.  However, I don't understand the argument that this would allow for double spends.  My idea was rather that the second coinbase transaction with the same TXID would rather be LOST if ever there was a transaction using this TXID as an input, because it would be considered "spent".  I thought an output was considered "spent" if its TXID appeared somewhere in a future input of a transaction.  What was the mechanism of "double spending" that was corrected with bip30 and bip34 ?

[OcTradism]

My idea was rather that the second coinbase transaction with the same TXID would rather be LOST if ever there was a transaction using this TXID as an input, because it would be considered "spent".

TXID is all zeros but there is a height of block in each Coinbase transaction. So two Coinbase transactions for two different blocks are different with each other.

Learn more about Coinbase transactions.
https://learnmeabitcoin.com/technical/mining/coinbase-transaction/
https://github.com/focusgrowth/Mastering-Bitcoin-/blob/develop/ch06_transactions.adoc#coinbase-transactions

[wonkelteut]

My idea was rather that the second coinbase transaction with the same TXID would rather be LOST if ever there was a transaction using this TXID as an input, because it would be considered "spent".

TXID is all zeros but there is a height of block in each Coinbase transaction. So two Coinbase transactions for two different blocks are different with each other.

Having to include the height of the block is exactly what bip34 was about IN ORDER to have the TXID of the coinbase transactions different.  It is argued that bip30 and bip34 were introduced to avoid the possibility of a double spend of the coinbase transaction OUTPUT.  But my question is: how was that possible, even before bip30 and bip34 ?  I'm of course not talking about the empty TXID of the coinbase transaction INPUT itself, but of the TXID of the coinbase transaction as a whole, that will be used to spend its output.  It is THIS txid (of the coinbase transaction as a whole) that could be the same for different coinbase transactions in different blocks by the same miner before bip34, and it was claimed that the fact that there were identical outputs with same TXID could lead to double spend.  THIS claim is what I don't understand because in my understanding, it would rather have led to LOSS of coins, not of double-spend.

In other words: how could the fact that there were transactions with identical TXID lead to double spends, and not, as I understand it, to loss of one of them ?  Because in my understanding, once a TXID is used as an input, it is considered spent, so if you spend the first of your identical outputs, you cannot spend your second one, because its (identical) TXID has already been put in an input and should hence be considered spent even if it isn't for real.

Learn more about Coinbase transactions.
https://learnmeabitcoin.com/technical/mining/coinbase-transaction/

I used that site amongst others, thanks :-)

[hosemary]

What was the mechanism of "double spending" that was corrected with bip30 and bip34 ?

I don't think it's appropriate to use the term "double-spend" here.

According to BIP30, blocks can't include a transaction with the same hash as a not-fully-spent transaction.
Before implementation of BIP30, blocks could include a transaction with the same ID as an exsiting transaction, even if not all outputs of that existing transaction had been spent. This bug made the coins generated by blocks 91722 and 91812 unspendable because in the UTXO set, they were replaced by the coins generated by blocks 91880 and 91842 respectively.

According to BIP34 (which was introduced some time after BIP30), the scriptsig of coinbase transactions must contain the block height. This prevents coinbase transactions from being identical to each other and therefore in practice it's no longer possible that two coinbase transactions have the same transaction ID.

[wonkelteut]

What was the mechanism of "double spending" that was corrected with bip30 and bip34 ?

I don't think it's appropriate to use the term "double-spend" here.

According to BIP30, blocks can't include a transaction with the same hash as a not-fully-spent transaction.
Before implementation of BIP30, blocks could include a transaction with the same ID as an exsiting transaction, even if not all outputs of that existing transaction had been spent. This bug made the coins generated by blocks 91722 and 91812 unspendable because in the UTXO set, they were replaced by the coins generated by blocks 91880 and 91842 respectively.

According to BIP34 (which was introduced some time after BIP30), the scriptsig of coinbase transactions must contain the block height. This prevents coinbase transactions from being identical to each other and therefore in practice it's no longer possible that two coinbase transactions have the same transaction ID.

Ah, OK, this is also how I understood it: these identical TXID render some "honest" UTXO unspendable, there's no way to turn this into a double spend vulnerability, as I thought.

I had read this here:

https://www.learnbitcoin.com/glossary/bip-30

BIP 30, detailed in BIP-30, was introduced to address a rare exploit scenario where a user could create a new transaction with exactly the same inputs and outputs as a prior one, generating identical transaction IDs. This could confuse the network or certain wallet implementations, potentially enabling subtle double-spend attacks.

I wondered what could have been these double spend attacks...

Thanks for the clarification !