I am writing a program that uses RPC to poll bitcoind for information about blocks, transactions, inputs and outputs and insert them into a database. After testing the output for the transactions within one block (specifically block #308799) I found that the number of outputs for some of the transactions in that block (according to bitcoind) were different from when I had originally inserted that transaction's data into the database. The transactions that threw these errors have the following transaction hashes
3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18
70ab887ea76c1c0fa3e4095f2696c7cb53231f9c8f16e2cbe9bd3c49a1f40dbd
3dff1e7732a45e4a0b568220cdad1aaeba1ba871bcc73767560bb6da6ff48273
if we look at the output data for the first transaction hash listed above, we found it looks like this
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
| id | txHash | type | dstAddress | value | offset | regSigs |
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
| 109811502 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC | 0.000078 | 0 | 1 |
| 109811503 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig | 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E | 0.000078 | 0 | 1 |
| 109811504 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC | 0.000078 | 1 | 1 |
| 109811505 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig | 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E | 0.000078 | 1 | 1 |
| 109811506 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | pubkeyhash | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC | 0.0073245 | 2 | 1 |
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
Note that they only different in the outputs with the same address only differ in their offset value. However, if we compare this to the info found on blockchain.info and on bitcoind for this transaction, located at
http://blockchain.info/tx/3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18we find that there are only three transactions. There's still one regular pubkeyhash, but 2 of the multisig outputs have disappeared. The same pattern follows for the other two transactions; the same number of regular type outputs are listed on both my database, bitcoind, and on blockchain.info, but the number of multisig outputs is less on blockchain.info and bitcoind than on my database.
Now that I've given the background on my problem, my question is:
Can someone explain to me what is going on with these multisig outputs? Since I'm using bitcoind as a data source and then putting this data into my database, it seems correct to assume that at one point bitcoind really thought there were 5 outputs for that first transaction hash. My guess that bitcoind went back at a future point in time and updated that transaction's outputs, but I have no idea why or how because I don't understand the technical aspects of a multisig transaction. Any light shed on this would be great as I'll need to make the changes to my data-mining scripts as soon as possible if there is something harmful in keeping the transactions with a greater number of multisig outputs.