Why is the relationship between tx and block many to many?

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?

bvpx

Posted 2013-07-19T21:22:25.963

Reputation: 1 052

Answers

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.

Pieter Wuille

Posted 2013-07-19T21:22:25.963

Reputation: 54 032

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 getblockhash it 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 through getblockhash.Pieter Wuille 2013-07-20T09:36:31.373

I'm sorry, I am a bit confused with your answer. You said it's not possible to find a transaction twice by calling getblockhash locally. Yet you also say getblockhash gives 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" with getblockhash?bvpx 2013-07-20T18:09:06.400

getblockhash gives you the hash of a block at a particular height in the currently active chain. When you're requesting an actual block through getblock you can specify any block hash, including of other blocks.Pieter Wuille 2013-07-20T21:46:23.963

Okay, so when you do getblockhash then getblock via the RPC, is it possible to see two transactions in different blocks?bvpx 2013-07-20T21:51:43.180

No, 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.000

That's interesting! Thank you for that information. This has been demystified :)bvpx 2013-07-20T22:31:10.797