Topic: Can a transaction be included in multiple blocks? (Read 2856 times)
But 100 from it can still be spent - they are in UTXO DB, except as single records, instead of doubled.
Quote
keeping it backward compatible wouldn't rather be worth these 100 BTC, for which most likely nobody has a key anyway.
200 btc to be correct https://blockchain.info/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
https://blockchain.info/tx/e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468
I know this thread is old, but I came to it first, and then found an example of a transaction hash being in multiple non-forked blocks in the block chain. The blocks that contain the transaction with hash
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.
This is a known bug in the early days of bitcoin. I don't think it is possible any longer to have 2 coinbase transactions with the same transaction hash.
It wasn't a bug, but the initial design.
BerkeleyDB that was used by the project back then had no problems handling records with non-unique keys.
After Satoshi had left, guys who took over the development replaced BerkeleyDB with LevelDB. And LevelDB only works with unique keys.
Whoever made the decision back then apparently did not care about handling non-unique IDs anymore (in reality only coinbase could have non-unique IDs), so they essentially changed the block chain protocol at that point. Which was a good decision, IMHO, since there were only 2 txs like this while the architectural complication of keeping it backward compatible wouldn't rather be worth these 100 BTC, for which most likely nobody has a key anyway.
It is not a fist time when I read misinformation about this had being an alleged bug.
You guys better get your records straight, because in fact it was not a bug - such was the initial design and the original implementation had no problems whatsoever with handling same TX IDs.
Then in blocks version 2 they started to require a block height value inside the coinbase, which makes it now impossible to replicate a previous TXID, even if the miner had really wanted to.
I know this thread is old, but I came to it first, and then found an example of a transaction hash being in multiple non-forked blocks in the block chain. The blocks that contain the transaction with hash
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.
This is a known bug in the early days of bitcoin. I don't think it is possible any longer to have 2 coinbase transactions with the same transaction hash.
I know this thread is old, but I came to it first, and then found an example of a transaction hash being in multiple non-forked blocks in the block chain. The blocks that contain the transaction with hash
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.
d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.
You could have the same transaction appearing in a block in both the main chain and a side chain temporarily when there was a fork.
Say you have a fork at A below:
A --- B --- C --- D (main chain)
\
\
E --- F (side chain)
The same transaction might appear in, say, blocks B and F. The two forks temporarily offer a different view of which transactions were confirmed until one dominates and the side chain gets reorganised. When the side chain gets reorganised the transactions in blocks E and F that are not yet in the main chain go back into the 'pot' for the miners to grab. Our transaction is already in the main chain (in block B) so the miners would ignore it.
Say you have a fork at A below:
A --- B --- C --- D (main chain)
\
\
E --- F (side chain)
The same transaction might appear in, say, blocks B and F. The two forks temporarily offer a different view of which transactions were confirmed until one dominates and the side chain gets reorganised. When the side chain gets reorganised the transactions in blocks E and F that are not yet in the main chain go back into the 'pot' for the miners to grab. Our transaction is already in the main chain (in block B) so the miners would ignore it.
Can a miner include a transaction in a block, if that transaction has already been confirmed to the block chain?
No, as the inputs of the transaction are already consumed by the first transaction, the second one will be considered a double spend (even without specific code to detect this case).Quote
Would that whole block be rejected?
The whole block will be considered invalid and ignored by other nodes.
Quote
Would just the duplicate translation be rejected and the remaining transactions be accepted?
Blocks are always accepted or rejected as a whole. There is no middle ground.
Quote
Or would the block be accepted just fine, but the miner wouldn't be rewarded the transaction fee for the duplicate transaction?
The fee of a transaction is defined as the value of its outputs minus the value of its inputs. As its inputs do not exist anymore for the second instance of the duplicate, you can't even talk about a notion of fee. These things only make sense when the transaction is valid.
Can a miner include a transaction in a block, if that transaction has already been confirmed to the block chain?
Would that whole block be rejected? Would just the duplicate translation be rejected and the remaining transactions be accepted? Or would the block be accepted just fine, but the miner wouldn't be rewarded the transaction fee for the duplicate transaction?
or something completely different....
Would that whole block be rejected? Would just the duplicate translation be rejected and the remaining transactions be accepted? Or would the block be accepted just fine, but the miner wouldn't be rewarded the transaction fee for the duplicate transaction?
or something completely different....
Jump to: