unique identifier of a transaction

[killerstorm]

What can be an unique identifier of a transaction in view of BIP 30?

Apparently transactions with same hash can appear in different blocks.

What's about txhash+block_number?

Is it possible to have transactions with same hash in one block? BIP 30 doesn't say anything about it, but perhaps it is mentioned in some other rule.

If it is possible, then I guess the only identifier is a position in the blockchain, i.e. block hash + index of transaction within block.

[1715030647]

1715030647

[1715030647]

1715030647

[1715030647]

1715030647

[1715030647]

1715030647

[kjj]

{blockhash,index} is unique.  As would be {blockhash,transactionhash} or even {transactionhash,blockheight}.

[Zeilap]

Is it possible to have transactions with same hash in one block? BIP 30 doesn't say anything about it, but perhaps it is mentioned in some other rule.

It's really just the same rule. You can't have 2 live transactions (those with unspent outputs) with the same hash. See https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2105.

If it is possible, then I guess the only identifier is a position in the blockchain, i.e. block hash + index of transaction within block.

Yes. Though you have to deal with the case where the transaction isn't in the blockchain separately.


Basically from the view of the reference client, there is no need for the identifier to be unique forever. The only need for looking up transactions is to get their unspent outputs. Once the outputs are spent, they never need to be looked up again, so the identifier can be reused.

[killerstorm]

It's really just the same rule. You can't have 2 live transactions (those with unspent outputs) with the same hash.

No, it is a different rule.

BIP 30 essentially says that once all outputs are spent, it can appear again. But it is possible to create a transaction and spent all its outputs within one block, isn't it? Thus this transaction won't be live.

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2105

Hmm, this is interesting. It basically says that "This is caught by ConnectInputs()", but is it?

Perhaps it is meant that CheckInputs will detect transactions which try to spend same outputs, but in theory if transactions can reappear, it would be different outputs.

So it is possible that line 2105 is a rule on its own...

Basically from the view of the reference client, there is no need for the identifier to be unique forever. The only need for looking up transactions is to get their unspent outputs. Once the outputs are spent, they never need to be looked up again, so the identifier can be reused.

Yep. Unfortunately this doesn't work so well for colored coins...

[killerstorm]

{blockhash,index} is unique.  As would be {blockhash,transactionhash} or even {transactionhash,blockheight}.

Thanks. {transactionhash,blockheight} is what I wanted to use, but wasn't sure.

[kjj]

{blockhash,index} is unique.  As would be {blockhash,transactionhash} or even {transactionhash,blockheight}.

Thanks. {transactionhash,blockheight} is what I wanted to use, but wasn't sure.

I was going to add that {transactionhash,blockheight} needs special handling for reorgs, but really, all of these do anyway.

Note that other than the series of identical generate transactions, or spending one of the same, making a duplicate transactionhash is effectively impossible.

[TierNolan]

Thanks. {transactionhash,blockheight} is what I wanted to use, but wasn't sure.

This one can only be used once the transaction is added to a block.

Also, the odds of 2 transactions hashing to the same hash is extremely low.  The only reason it happened before is because you could create 2 coinbase transactions that were equal.

The new rule is that all coinbases transactions must be unique, since they include the chain height.

[Zeilap]

But it is possible to create a transaction and spent all its outputs within one block, isn't it? Thus this transaction won't be live.

Heh, good point!

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2105

Hmm, this is interesting. It basically says that "This is caught by ConnectInputs()", but is it?

Short answer: No.
Longer answer: 'ConnectInputs()' doesn't exist anymore in the code. It never explicitly checked for duplicates because it was a check of a single transaction, so it couldn't know about the other transactions in the block. However, if the transactions are duplicate then updating the UTXO set will fail (presumably what it meant). If a true collision of different transactions this isn't true (as far as I can see).
The same is true now, the code has just moved to CheckInputs and UpdateCoins.