3
1
I was looking through the code for ABE, and I discovered that the relationship of blocks to transactions is many to many.
Why are some transactions stored in the transaction lists of multiple blocks?
3
1
I was looking through the code for ABE, and I discovered that the relationship of blocks to transactions is many to many.
Why are some transactions stored in the transaction lists of multiple blocks?
3
Within one chain of blocks, every transaction can only occur once. However, the data structure people frequently call "the block chain" is actually a tree structure, with one root (the genesis block) and different branches. The longest valid branch of this tree is called the active block chain, but occassionally, during a reorganisation, nodes switch to another branch (usually only the last 1-2 blocks change). Any transactions that were in the old branch but not in the new are then attempted to be mined again when possible. This results in one transaction being in several blocks within the tree - but not the same chain.
There existed another way. Early on, there was a possibility for two coinbase transactions to be identical. This occurred in blocks at height 91842 and 91880. It has since been made illegal and later impossible through BIP30 and BIP34.
Okay, so when I use the RPC to "getblockhash 50000" let's say, then I open that block and it has a tx with ID ae345, could I then open another block (50001 or something) and find the same tx ae345 listed there? Is the RPC from bitcoind getting its information from the network or the blockchain on my computer? Does the blockchain on my computer change when the invalid branch is dropped?
I'm not really sure about the timing of accepting blocks into the blockchain, or the way the RPC client accesses that data. – bvpx – 2013-07-19T23:30:05.870
When you use
getblockhashit will give you the hash of the block in the currently active chain. So no, except for the duplicated coinbases, you will never find a transaction twice that way. You need to search in blocks that are not in the main chain. The RPC queries the local database, which has all blocks (also those not in the main chain) you node has ever accepted, but only the active ones are indexed and accessible throughgetblockhash. – Pieter Wuille – 2013-07-20T09:36:31.373I'm sorry, I am a bit confused with your answer. You said it's not possible to find a transaction twice by calling
getblockhashlocally. Yet you also saygetblockhashgives you a block in the currently active chain, but "also those not in the main chain", and that you'd "have to search in blocks that are not in the main chain" to be able to find a transaction twice. Can you specifically search for blocks "not in the main chain" withgetblockhash? – bvpx – 2013-07-20T18:09:06.400getblockhashgives you the hash of a block at a particular height in the currently active chain. When you're requesting an actual block throughgetblockyou can specify any block hash, including of other blocks. – Pieter Wuille – 2013-07-20T21:46:23.963Okay, so when you do
getblockhashthengetblockvia the RPC, is it possible to see two transactions in different blocks? – bvpx – 2013-07-20T21:51:43.180No, as that way you'll only reach blocks in the active chain, and within a given chain, no duplicate transactions are possible. – Pieter Wuille – 2013-07-20T21:53:45.877
I see. So is there a way to search for duplicate transactions? Also, why does blockchain.info list some transactions in multiple blocks? How do they find those alternate chains with the same transaction in separate blocks? Sorry for asking so many questions, this is a very confusing and unclear topic. – bvpx – 2013-07-20T21:55:19.270
Blockchain.info doesn't use bitcoind, they maintain many more indexes than bitcoind does. Inactive blocks are not interesting for bitcoind, and aren't indexed. If you know the hash of an inactive block, you can still request it through
getblock, but there is no way to get a list of such inactive blocks for example. – Pieter Wuille – 2013-07-20T22:06:55.000That's interesting! Thank you for that information. This has been demystified :) – bvpx – 2013-07-20T22:31:10.797